[General Algorithme] 3D engines
Moderator: MaxCoderz Staff
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
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
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- Fr0stbyte124
- Regular Member
- Posts: 75
- Joined: Thu 16 Feb, 2006 9:59 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.
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.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
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 ).
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 ).
-
- Regular Member
- Posts: 86
- Joined: Fri 17 Dec, 2004 8:20 pm
- Contact:
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?
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?
-
- MCF Legend
- Posts: 1601
- Joined: Mon 20 Dec, 2004 8:45 am
- Location: Budapest, Absurdistan
- Contact:
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: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.
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.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.
- GuillaumeH
- Regular Member
- Posts: 143
- Joined: Fri 17 Dec, 2004 8:30 pm
- Contact:
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
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.
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.
-
- Calc Guru
- Posts: 901
- Joined: Tue 29 Mar, 2005 9:13 pm
- Location: almost..........there........
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!
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!
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
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- GuillaumeH
- Regular Member
- Posts: 143
- Joined: Fri 17 Dec, 2004 8:30 pm
- Contact:
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>
<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>
- Fr0stbyte124
- Regular Member
- Posts: 75
- Joined: Thu 16 Feb, 2006 9:59 pm
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...
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...