OpenGL or equivalent
aanrudolph2
Posts: 4
Hi, all.
I know I (and others) have asked about 3D graphics on the Propeller platform before. The answers I remember receiving were things like "too little RAM" and whatnot.
I have a couple of follow-up questions regarding this issue. (1) Exactly how much RAM is required to produce a simple OpenGL functionality on a Propeller-based platform? I am aware the Propeller has about 32k onboard, but I believe, using external circuitry, that can be expanded by a significant amount. (2) Where would be a good starting point to find basic algorithms for drawing polygons and whatnot for beginning this ambitious project? (3) How many people do you (as the responder to this post) know have tried and failed at simulating OpenGL on a Propeller?
I appreciate it.
Aaron.
I know I (and others) have asked about 3D graphics on the Propeller platform before. The answers I remember receiving were things like "too little RAM" and whatnot.
I have a couple of follow-up questions regarding this issue. (1) Exactly how much RAM is required to produce a simple OpenGL functionality on a Propeller-based platform? I am aware the Propeller has about 32k onboard, but I believe, using external circuitry, that can be expanded by a significant amount. (2) Where would be a good starting point to find basic algorithms for drawing polygons and whatnot for beginning this ambitious project? (3) How many people do you (as the responder to this post) know have tried and failed at simulating OpenGL on a Propeller?
I appreciate it.
Aaron.
Comments
The core Open GL library on my Debian Linux box here is 14M Bytes!
Perhaps one can get it down to a tenth that size, after all the Mesa OpenGL implementation used to run on Amigas., but you are still going need heaps of external RAM. Maybe Jazzed's 32MByte solution.
It's going to be slow. Might as well render your polygons with a chisel on a stone tablet.
Better to use one of those new ARM processors with OpenGL hardware acceleration built in. As used in my Android phone. Then hook that up to a Prop or two to make use of it's I/O. That's my plan anyway.
This kind of thing happens at moderate TV resollution. Coupla hundred pixel screen tops, and it takes most of a Propeller to do.
Baggers and Coley built a serially controlled propeller graphics system. It's approachable for games and such.
The other thing we have is Chip Gracey's graphics COG. It's filled with 2D primitives, and works on a command basis. That cog can be told where a bitmap display is, and what it's coordinates should be. From there, one can put commands into a HUB buffer, to be run by that COG, on the display. It's capable of simple shapes, line, arc, text, filled shapes. It can also do some simple windowing and buffering.
(not window like a pc, but a window as in a portion of a display being operated on, or buffered)
Have you run graphics_demo.spin? If not, do that, or look at the code for it, which is included with the free downloadable IDE. That's a great example of where the Propeller is graphically.
One issue that hasn't been covered is you need a way to make sure that near triangles cover up the far triangles. The typical ways to do this are a depth-buffer (storing the depth of each pixel drawn so far), which is _not_ feasible on the prop, and the "painter's algorithm", where you draw everything in order from far to near. This requires a fast sort algorithm, and the overdraw can be horrible, and sometimes the order can still be wrong (imagine 2 intersecting triangles, at an angle to each other...there's no draw order that works in all cases. (There are many other options, but these are the easiest and most common).
You may want to check out http://bellard.org/TinyGL/, as a nice software implementation of some OpenGL functionality.
Jonathan
Why is it slow... well, it's not that "simple" for starters, here's a list of reasons that I can think of off the top of my head without thinking too heavily into this reply.
1. There is NO multiply/divide in hardware, it all has to be done in software, so you get your XYZ, then you have to do a World Matrix calculation, to take it from it's local space to 3D space, then you have to do a Camera Matrix calculation to get it into a local camera space, then you have to do a Perspective Matrix calculation, to then give you screen coordinates. so for each vertex you need a few calculations, you can concatenate all them into one matrix, so that you then only have to do one set of matrix multiplies per vertex.
2. You have to do those calculations to EVERY vertex in your model, re-adjusting the World Matrix when you use a different model. ( Also, this isn't including models with Bones, that takes things to another level of slowness. )
3. You then have to get the propeller to physically draw it, so then depending on which method you choose in rendering your poly, say you're not wanting to slow down things a lot more, doing gouraud shading, or textures, ( as you then need to take into consideration, blending and more delta's for traversing through the poly rendering. ) so just with flat shading, you need the delta values for traversing down the edges of the triangles, then you need to fill in the ram, now again, this can get slower if you don't have byte per pixel, and if you have to then add bit manipulation, to fill the horizontal strip.
So, Yes, OpenGL has made it too easy for programmers to get things onto the screen on PCs and Macs, because the hardware graphics cards take a lot of the calculations away from you, where-as on the propeller, it's just the propeller, your code has to do EVERYTHING, from calculating where to put the vertex to what part of memory that you've set aside for screen to then fill with values to set the new pixel colours.
Not much of a savings, but some little savings.
(great post Baggers)
If your goal is to get 3D running on the Prop, it's probably just barely doable. But it will really make you yearn for the Prop ][. If you want to run OpenGL, the idea about using an ARM with an OpenGL accelerator is probably the best idea.
-phar
You remind me of something, in the days of 25MHz 386 PCs with no floating point running MSDOS we had a 3D demo. In the demo was a model of some suburban streets, bungalows, gardens, roads, trees etc. There were occasional people walking around and cars on the roads. You could get a drivers eye view as you drove your car around.
Amusingly you could park your car in front of a pedestrian and he would continue his walking action without making any progress. Or you could drive through the walls of a house and checkout the inside of the living room.
No idea if this was from Intel but it was a pretty amazing demonstration of what can be done with such limited processing power.
My understanding was that I was like one of two users of IGL and, as I mentioned, it was not a functioning product, I had to do a bit of work to get it running. I would think the demo you saw was more optimized than IGL, my memory was that things didn't get interesting until you got over 100 MHz. But from my little exposure to 3D graphics programming I could see that there were a lot of shortcuts you could take to get 3D on a slow integer cpu; living in a 16 bit world space, not doing the full [4x4]x4 transform, using fixed point math instead of floating point.
To quantify things, I would think you could get something like the original Doom graphics without the texture mapping on the Prop. If you have to go to external memory to read in texture maps, things would really slow down. In order to render shading in low-res modes I used dithering; the result was surprisingly good. To be useful, somebody would have to write code to read in some standard 3D format, then you'd be able to use 3D modeling software to create content. I remember in my own case when I got the renderer running, I discovered it would be infinitely more work to create content without modeling software than it was to display it.
But I think this thread illustrates the reality that there isn't really that much interest in 3D on the Prop or we'd already be there. From what I've read about the Prop ][ it will be far more 3D capable. From a game programmer's standpoint, when you get to the point where you can display Quake 1-3 era models and the .MAP level format, you have access to a huge amount of existing content. You get those hard-core Prop game programmers to do something interesting and then you're off and running.
-phar
Jonathan
Star Glider on the Prop would be nice. It's about the last computer game I ever played.
ericball, did you not see my wolfenstein render demo?
http://www.youtube.com/watch?v=6vp5krplhxE
Coley, brilliant!.
Don't worry, you won't have to humbly eat those words.
Cheers Coley