Hmmm, well, looks like people want the SD card interface, that's definitely important. And another prop co-processor. Let me see what I can come up with that won't break the bank at retail.
But, if I put one prop, I would probably put 2 [noparse]:)[/noparse]
Well, without 3d support, you can do an estimate by looking at the average polys per frame which is in the hundreds to low thousands for that game per frame, then each poly is 25x25 pixels on average, they are gouraud shaded, texture mapped, mip mapped, transparancy pass, blah blah. A lot of calcs per pixel. Based on all that you can come up with a general amount of mips needed per frame. Of course, this assumes a bitmap mode, so a number of cogs are set aside for the bitmap display, the rest for rendering.
But, 3-4 props could probably pull it off something like it, since the nintendo 64 more or less uses very small 32x32 textures, and doesn't have a zillion polys on the screen at once by design. The system used a pair of 64 bit risc processor at like 50-100 mips each. But, remember pure mips don't help if you can't seperate your problem and move all the memory around efficiently, and with the limited memory of the prop, you would have to use a shared large external SRAM and try and seperate the 3D pipeline maybe, or if you really want a headache seperate the rendering in scanlines per cog kind of thing.
Might be fun for someone nutty with a lot of time [noparse]:)[/noparse]
Might be fun for someone nutty with a lot of time [noparse]:)[/noparse]
Ha ha, nice. Seriously though, I actually am working on this.
AndreL said...
But, remember pure mips don't help if you can't seperate your problem and move all the memory around efficiently, and with the limited memory of the prop, you would have to use a shared large external SRAM and try and seperate the 3D pipeline maybe, or if you really want a headache seperate the rendering in scanlines per cog kind of thing.
Yeah so actually the "headache" approach is the one I'm shooting for. By taking the scanline approach I can cut a huge chunk out of the RAM requirements, have 1-byte per pixel color, and still do triple buffering on prerendered scanlines without needing too much RAM for that. I also believe I can beat other architecture's 3-d implementations' speed limitations by not recalculating some things every frame. For instance, back face culling and field-of-view culling need not be recalculated every frame. Instead, that can be just a flag bit on the objects to be rendered, and the engine could just examine say, 1/6th of all the objects between each frame to determine what to flag as visible or not visible, while still taking no more than a 10th of a second to display a new object. Unless you're spinning the camera, not everything in the field of view is going to go in or out of view in one frame.
I also plan to have "symmetry" flag bits on the 3-d object models. For instance, if your space ship is symmetrical from left to right, you just store the triangles in memory to represent 1/2 of the shape, and set a flag that tells the engine to mirror the other half when it renders it.
Edit: But your post does give me quite a bit of encouragement; I had thought the N64 had more processing power than that. I realize MIPS doesn't tell the full story, but it is heartening to know that we are at least approaching the same ballpark. Even if there's no guarantee we can make use of enough MIPS to do this, it's heartening to know that the power may be there if I can figure out how to harness it.
Post Edited (Dennis Ferron) : 6/7/2007 6:30:37 AM GMT
Well, object culling is great, but this isn't going to help the z-buffering problem or the sorting problem, you are going to need to z-buffer things and or use a bsp tree with potentially visible set, etc. Also, big diff between outdoor and indoor engines as per culling opportunities. Occluders are all over the place in outdoor sets, but indoor you want to use portals and a PVS.
Also, doing scanline algorithms are theoretically sound, but trying to implement them across processors is not easy, the amount of data movement can become a bottleneck, also, all the re-assembly has to be thought out. Anyway, as long as you think about it all, its doable no doubt. The problem is that you have a set of polys and ALL the calcs for all the polys have to be replicated as you run you edge scan algorithms, then each processor can run its horizontal processing independently. So there are lots of ways to to cook this chicken a master that does edge scan computation for all polygons on a scanline and passes the in/out edges and interpolants to the processor pool for processing. Or one can do something where each processor just gets a poly and works on it, buffers the polygon, then another pass does the merging with the z-buffer or whatever rendering algorithm, or you can brute force with a painters algorithm, and use blits based on the circumscribed rects around each resulting poly buffered locally to re-assemble.
But, your mirroring things won't really work based on the camera angle, after the camera and perspective transform, symetry doesn't help you the vertex list still needs to be transformed, also, lit properly, etc. and clipped potentially. The only time something like that would work is if you are looking dead on an object at the point of bi-lateral symmetry, not to mention all the surface normals will still be all over the place for your lighting calcs and simple transforms don't really help. The only real help symmetry gives you in the pipeline is data compression really, you don't have to store an object entirely you can derive it from symmetry.
Anyway, billion ways to do things [noparse]:)[/noparse] Lastly, I would forget about perspective correct texture mapping and stick with affine mapping and smaller polys, works fine on the PSX, better to have more lighting and geometry. The perspective correct really ecks the algorithms and adds a lot of computation. Many of the engines I have done though I use a hybrid approach of course, switching based on z distance blah blah, so that's another option. But, if you start perspective correct rendering terrain -- ouch!!!!
The 32-bit data width is a lifesaver for fixed point math as well, a 16.16 or 24.8 format would work fine.
Good luck man! Reminds me back in the early 90's when we were all doing software 3D stuff, there was always a way to make it faster.
Well, I'll be waiting to see this happen, Dennis! Well, if the propeller 2 comes out soon and a new Hydra uses it, well: I think you could do this even more easily with less restraint if you still use the SD card or SRAM.
·Andre, do you think that if the new card had 4 propeller co-processors and 1 3D assist that you could make insane multiprocessing programs in 3D?
For example, making 30 3D objects spinning in different directions flipping and flying at various times as particles fly back and forth far and away as a stick moves?
Comments
But, if I put one prop, I would probably put 2 [noparse]:)[/noparse]
Andre'
But, 3-4 props could probably pull it off something like it, since the nintendo 64 more or less uses very small 32x32 textures, and doesn't have a zillion polys on the screen at once by design. The system used a pair of 64 bit risc processor at like 50-100 mips each. But, remember pure mips don't help if you can't seperate your problem and move all the memory around efficiently, and with the limited memory of the prop, you would have to use a shared large external SRAM and try and seperate the 3D pipeline maybe, or if you really want a headache seperate the rendering in scanlines per cog kind of thing.
Might be fun for someone nutty with a lot of time [noparse]:)[/noparse]
Andre'
Ha ha, nice. Seriously though, I actually am working on this.
Yeah so actually the "headache" approach is the one I'm shooting for. By taking the scanline approach I can cut a huge chunk out of the RAM requirements, have 1-byte per pixel color, and still do triple buffering on prerendered scanlines without needing too much RAM for that. I also believe I can beat other architecture's 3-d implementations' speed limitations by not recalculating some things every frame. For instance, back face culling and field-of-view culling need not be recalculated every frame. Instead, that can be just a flag bit on the objects to be rendered, and the engine could just examine say, 1/6th of all the objects between each frame to determine what to flag as visible or not visible, while still taking no more than a 10th of a second to display a new object. Unless you're spinning the camera, not everything in the field of view is going to go in or out of view in one frame.
I also plan to have "symmetry" flag bits on the 3-d object models. For instance, if your space ship is symmetrical from left to right, you just store the triangles in memory to represent 1/2 of the shape, and set a flag that tells the engine to mirror the other half when it renders it.
Edit: But your post does give me quite a bit of encouragement; I had thought the N64 had more processing power than that. I realize MIPS doesn't tell the full story, but it is heartening to know that we are at least approaching the same ballpark. Even if there's no guarantee we can make use of enough MIPS to do this, it's heartening to know that the power may be there if I can figure out how to harness it.
Post Edited (Dennis Ferron) : 6/7/2007 6:30:37 AM GMT
Also, doing scanline algorithms are theoretically sound, but trying to implement them across processors is not easy, the amount of data movement can become a bottleneck, also, all the re-assembly has to be thought out. Anyway, as long as you think about it all, its doable no doubt. The problem is that you have a set of polys and ALL the calcs for all the polys have to be replicated as you run you edge scan algorithms, then each processor can run its horizontal processing independently. So there are lots of ways to to cook this chicken a master that does edge scan computation for all polygons on a scanline and passes the in/out edges and interpolants to the processor pool for processing. Or one can do something where each processor just gets a poly and works on it, buffers the polygon, then another pass does the merging with the z-buffer or whatever rendering algorithm, or you can brute force with a painters algorithm, and use blits based on the circumscribed rects around each resulting poly buffered locally to re-assemble.
But, your mirroring things won't really work based on the camera angle, after the camera and perspective transform, symetry doesn't help you the vertex list still needs to be transformed, also, lit properly, etc. and clipped potentially. The only time something like that would work is if you are looking dead on an object at the point of bi-lateral symmetry, not to mention all the surface normals will still be all over the place for your lighting calcs and simple transforms don't really help. The only real help symmetry gives you in the pipeline is data compression really, you don't have to store an object entirely you can derive it from symmetry.
Anyway, billion ways to do things [noparse]:)[/noparse] Lastly, I would forget about perspective correct texture mapping and stick with affine mapping and smaller polys, works fine on the PSX, better to have more lighting and geometry. The perspective correct really ecks the algorithms and adds a lot of computation. Many of the engines I have done though I use a hybrid approach of course, switching based on z distance blah blah, so that's another option. But, if you start perspective correct rendering terrain -- ouch!!!!
The 32-bit data width is a lifesaver for fixed point math as well, a 16.16 or 24.8 format would work fine.
Good luck man! Reminds me back in the early 90's when we were all doing software 3D stuff, there was always a way to make it faster.
Andre'
For example, making 30 3D objects spinning in different directions flipping and flying at various times as particles fly back and forth far and away as a stick moves?