mirror/anarch
1
0
Fork 0
mirror of https://gitlab.com/drummyfish/anarch.git synced 2024-12-21 23:08:49 -05:00
Code Issues Projects Releases Wiki Activity

Update readme

Browse Source
This commit is contained in:
Miloslav Číž 2020-11-04 19:22:43 +01:00
parent 4f6936d293
commit c46b0477d1
2 changed files with 6 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@ -170,13 +170,17 @@ Because this "modern" technology is an extremely bad choice for building long-la
This game is suppost to be accessible, i.e. require only as many resources as necessarily needed, in order to run and compile even on "weak" and minimal computers, and to run long in the future, which is ensured by dropping dependencies and only relying on a C compiler, which will probably always be the highest priority piece of SW. After the technological collapse a C compiler will be the first SW we'll have to write, and with it this game will basically immediately be compilable.
### I can make this in "Unity" in a week.
Firstly that's not a question and secondly you misunderstand the essence of this project. Your game will merely *look* the same, it will be an insult to good programming, efficient technology, users' freedom, it won't offer the same independence, portability, performance, beauty, it will probably die along with your "Unity", it will be encoumbered by licenses of your asset store, it won't carry the important messages.
### How long did this take you to make?
Depends from where you count. From my [first experiments with raycasting on Pokitto](https://talk.pokitto.com/t/pokitto-is-on-the-way-what-games-should-i-make/1266/64?u=drummyfish) it's some two years of relaxed evening programming, with taking quite long breaks.
### I can make this in "Unity" in a week.
### What tools did you use to make this game?
Firstly that's not a question and secondly you misunderstand the essence of this project. Your game will merely *look* the same, it will be an insult to good programming, efficient technology, users' freedom, it won't offer the same independence, portability, performance, beauty, it will probably die along with your "Unity", it will be encoumbered by licenses of your asset store, it won't carry the important messages.
Only free software, preferably suckless tools: Vim text editor on Devuan GNU/Linux, mostly on a librebooted Lenovo X200 laptop. GIMP was used to make images and maps, python for small scripts and data conversions. Audacity and Blender and other programs were also used for making the trailer etc.
### But you're using python scripts, Javascript for the web port, the PC port depends on SDL etc. Don't you contradict yourself?

74
README.md.backup
View File

@ -1,74 +0,0 @@
> well I use discord typically. Gek#9082
I never use discord. Things I use or can use:
- e-mail
- IRC
- Matrix/Riot chat
- Diaspora
- Xonotic ingame chat :) We actually have pretty serious discussions in that game.
> Question zero: What is "SW" ?
software :)
> I've seen that pure C software renderer. In fact, I've spoken with its author.
It's truly impressive, I think in the video it even has linear filtering for the textures? Full HD on 60 FPS with this stuff must be running on a small supercomputer, or perhaps use some platform specific hacks? I dunno, the performance is awesome as hell. Anyway, the goal for S3L wasn't maximum speed, it tries to be platform independent and simple, which kills some potential performance boosts.
> (DDA) which is a floating point method.
I know DDA, it can be done without float (almost anything float can be done with just fixed point). I use it in raycastlib to trace rays.
At first I used DDA in S3L too, but sincerely I didn't figure out how to make that respect the rules of rasterizing adjacent triangles, i.e. to have no holes or overlapping pixels on triangle borders. I implemented the top-left rule my own way. Perhaps it can be done with DDA or some algorithm I don't know of, I didn't do much research actually.
> Yes I saw your game anarch
Yes, it's nearing completion now. I actually want it to be not just a game, but also a potential research/educational tool, a toy for hackers, a basis for other projects etc.
> physics engine I and a coding group (The C Chads) are designing. We want to *only* depend on SDL2 and an available C99 compiler.
This is very awesome, +1.
> Yes, all the software i'm writing is free software. The physics engine will be CC0.
You're my guy, I am actually planning a CC0 physics engine in the same style as S3L/RCL, but currently am busy with many other projects. I am so glad that someone is doing this stuff.
> Don't get me wrong, your rasterizer is *BEYOND* cool.
Thank you :)
> I'll be straight with you. How could I implement proper near plane culling into your model renderer? Particularly, how could I get the barycentric coordinates interpolating correctly?
I did some digging around in small3dlib.h while writng this email. You render unsorted on line 2589, in drawScene (Which happens to be the only functionality of your renderer i'm interested in, so I ain't worried about sorted)
> A near plane clipping will create at most two triangles from a single triangle (If one of the points fall behind the near plane)
```
________
\ /
\ /
____\ /
\/
```
Example implementation of near plane clipping from a fairly well-known coding 'tuber's implementation (Albeit in C++, not C99, and he releases under a modified BSD3. We can both agree, not acceptable for my use case)
https://github.com/OneLoneCoder/videos/blob/master/OneLoneCoder_olcEngine3D_Part3.cpp
(Line 322, int Triangle_ClipAgainstPlane)
If you wanted to clip the triangle and have the barycentric attributes come out correctly, you'd need to interpolate them for the new vertices, which would require a change in how S3L_drawTriangle works.
It'd be neat to *have* this interpolation correct, however it isn't necessary as we plan on doing flat color models. As long as the triangle index and model index passed to S3L_drawTriangle are the same for both clipped triangles (or the one, smaller triangle) it's 100%, totally fine. We'll be able to get ahold of the same normal, and do the same dot product, and get the same resulting flat color for the entirety of the triangle (And per your recommendation, use a per-triangle cache)
If you came up with a patch yourself for this specific case (Where we don't care about the barycentric attributes, but we want proper near plane culling) i'd switch your renderer immediately. *AND* I would ditch the GL implementation
Our renderer would already be using S3L_FLAT so you could even write a check to see if this attribute was enabled and provide a compiler error if S3L_CORRECT_NEAR_PLANE_CULL was enabled but S3L_FLAT was not... or forcefully enable it, which seems to be the convention of your library.
Thanks,
Gek