[General Algorithme] 3D engines

Timendus · Post by **Timendus** » Fri 03 Mar, 2006 2:35 am

Nice, cross-post...

I mean that I currently clear my gs buffers, decompress several full screen images and OR them with my gs buffers. I suppose that's not really copying data, but you copy the images over each other

If I want to have good looking textures in greyscale, what I intend to, I'll have to revise that completely and have much smaller (in width) pictures with a horizontal offset, not ORing them but overwriting the old vertical screen slice. So I would then be copying data I guess

The "best" thing would be to use an arbitrary size masked scaling sprite routine to put all the pieces on the screen, but I think that would be much too slow for greyscale... or wouldn't it? The same goes for having nonaligned vertical slices, shifting the bits around for every image will kill the performance I fear.

So, some improvements I have in mind are copying aligned slices instead of ORing the entire screen and using something that looks a bit more like raycasting to prevent drawing things that are out of sight... any other ideas..?

Edit: I've been drawing some ideas and stuff, and I think I know how I'm going to speed this up

So never mind me asking, I'll try this first

Fr0stbyte124 · Post by **Fr0stbyte124** » Fri 03 Mar, 2006 3:58 am

If I'm understanding right, does this program work like Quicktime's virtual scene applet? If that's the case, how is this different from existing raycasting techniques?

Timendus · Post by **Timendus** » Fri 03 Mar, 2006 12:00 pm

I wouldn't have a clue what Quicktime's virtual scene applet is capable of, and I know zip about existing raycasting techniques

Unlike some people here (like the brilliant coelurus

) I'm pretty much a 3D rendering virgin

All I ever did that was more complex than this was some crappy basic wireframe rendering, which sucked because it didn't properly detect what was behind and what in front of you and it rendered with a horrible "fish-eye" I believe it's called.

coelurus · Post by **coelurus** » Fri 03 Mar, 2006 3:07 pm

It's pretty motivating to see that my rantings are of good use to people, it almost makes me wanna get back to z80 to finish off a couple of unfinished projects I had. University, the plugin engine, playing guitar, being nerdy in general... Bah, no time

Filling (rather "touching") pixels ~= lethal, because the number of clocks add up tremendously. One good example is the secret in the 4th and last level in Gemini, which is easily found by the horrible drop in FPS (loads of items in that secret!). Every frame, _all_ objects (enemies, ammo boxes, health/armor packs etc) in the entire level are looped through and tested against the player FOV. Those considered visible are rendered. When you're in the huge final room, the game flows like butter in sunshine even though all objects are tested, but whenever the player looks directly towards the secret, meaning all items are rendered against the Z-buffer and therefore become invisible, it's like if the sun has fallen down and all the butter freeze.

Touching pixels is lethal, maths or physics is blazing fast, a golden rule that applies 8 out of 10 times (of course, it doesn't apply to graphical Duffing differential equation solvers or whatever

).

thecheat · Post by **thecheat** » Fri 03 Mar, 2006 10:20 pm

perhaps, just perhaps, you might be able to (in the example of a square room) draw up each "orientation" of the squares, it'd be one heck of a lot of sprites to draw, but, I'm correct in thinking that it would be pretty fast, right? (just tell me if you don't get what I'm saying)

Stickmanofdoom · Post by **Stickmanofdoom** » Sat 04 Mar, 2006 12:46 am

While drawing sprites is fast, the number of different orientations of a single polygon is so large that it would take a massive amount of memory to store all the data, with makes the technique impractical.

It seems to me that the most practical way to get a 3d engine for z80 calcs would be to get many community members involved in different parts of an engine. There seem to be so many things that are involved in making an engine that most people are overwhelmed with such a project. However, with the insight from experienced 3d coders and other skilled ASM programmers, I feel that it could happen.

Someone that can write a really fast polygon filling routine doesn't really need to know anything about z-buffering or BSP trees and vice-versa. Why not pool together our resources together and finally create something that people on this fourm have been asking about for quite some time?

CoBB · Post by **CoBB** » Sat 04 Mar, 2006 7:01 am

Stickmanofdoom wrote:It seems to me that the most practical way to get a 3d engine for z80 calcs would be to get many community members involved in different parts of an engine.

No! Why do so many people get the idea that adding more coders improves development? It's rather the opposite. Probably a full-blown OS is the only project which necessitates more than one coder, but even there two or three would be most likely enough.

Stickmanofdoom wrote:Someone that can write a really fast polygon filling routine doesn't really need to know anything about z-buffering or BSP trees and vice-versa.

That's quite an untypical setting. When someone is knowledgeable in this area, they are familiar with everything. There's no such thing as 'expert on polygon rendering', at least not on the level allowed by our favourite platform.

GuillaumeH · Post by **GuillaumeH** » Sat 04 Mar, 2006 2:27 pm

CoBB wrote: Why do so many people get the idea that adding more coders improves development?

Because the free sofware scene proves it ?

Jim e · Post by **Jim e** » Sat 04 Mar, 2006 2:56 pm

uhhmmm, no.

When it comes to z80 asm, the coders style is practically a finger print. It becomes very difficult to intergrate code together, and harder to keep it sycnronized. If you ever left a code on the shelf for more a few months, most of the time going back to it difficult because you are not in the same mindset as you were when you coded it.

The fact is most people plan and code on the fly, something that can't be done in group project. So either a massive planning is required, or make dependant code extremely self contained( handle all errors, do nothing that may risk collision, ie slow).

No this kind of project is a one coder deal. Maybe some one could build on top of an egine but generally making your own code is better, atleast more rewarding.

CoBB · Post by **CoBB** » Sat 04 Mar, 2006 2:58 pm

GuillaumeH wrote:Because the free sofware scene proves it ?

Not in the case of tiny projects allowed by this platform. And a 3D engine is definitely not something one person couldn't handle.

thecheat · Post by **thecheat** » Sat 04 Mar, 2006 3:54 pm

just to add my two cents, really, the only reason I'd want more than one person to help is if they've made a 3D engine in the past! I'd like to look over the coding (ASM) of an already created engine to help shape my thoughts on what it might look like.

the problem with multiple people is every one has something called: life. it usually doesn't work out too well. Now, having multiple people for a game does work, EX: one does storyline, one does engine, one does maps and one does the artistry.

I wanted to know about something, for a picture, does it take less space to code in hex or just 1's and 0's? hex is a pain!

Timendus · Post by **Timendus** » Sun 05 Mar, 2006 1:32 am

There is no difference between binary and hex. None whatsoever, except for the coder's convenience. Unless you meant taking less space in your source code file on your computer

GuillaumeH · Post by **GuillaumeH** » Sun 05 Mar, 2006 1:33 am

Remember, I answered to the question "Why do so many people get the idea that adding more coders improves development?". I'm convinced that for that precise case of a set of 3D routines, one person is enough.

<off-topic>
Still, not writing spaghetti code is possible in ASM, and work can be split for a big project that involves several aspects. I think development is generally not open enough in the Ti community. See all those projects that die without leaving any source code anywhere.
</off-topic>

DJ_O · Post by **DJ_O** » Sun 05 Mar, 2006 1:49 am

GuillaumeH wrote:See all those projects that die without leaving any source code anywhere.
</off-topic>

i hate that

Fr0stbyte124 · Post by **Fr0stbyte124** » Sun 05 Mar, 2006 2:27 am

Back on topic for a moment, how well would building a flat buffer to represent a ~120 degree FOV, and use a lookup table to distort it all at the same time? Not exactly sure how one would program that, or if it would even be more efficient than what you are doing, though.

Sorry about that. Back off-topic now. The most efficient setup I've seen is one person heading a project and posting the source. Then strangers look at it and tell him how foolish his coding is, and he goes and fixes it, so as to not look foolish

Good times...