Instead, I'm conjecturing about using the PropGFX as the 2D chip behind a 3D renderer.
One of my (Non µC) hobies is 3D, whether it be hardware or software rendered. Now, I'm conjecturing about making an MCU do 3D rendering and then passing the drawing off to a PropGFX. 3D rendering on the prop is quite difficult, mainly because the prop lacks hardware MUL/DIV. Instead, I was thinking of teaming the prop up with something more capable in that area, and the thought occured to use one of the 16-Bit PICs (PIC24/dsPIC) as the rasterizer to which a stream of triangles is sent. The rasterizer then scans along each triangle, and converts it into a seires of HLINES, which are sent off to the PropGFX. In this case, as many cogs as possible in the PropGFX should be dedicated to processing HLines
I'm still working out whether, to acheive decent framerates, 1 or 2 dsPICs would be needed (one to do the triangle rasterizing, and one to do the depth sorting and matrix transformations)
The main complexity on the 2D side with 3D rendering is that the display has got to be a framebuffer, not tiled. I think the highest the prop could feasibly do is 256x[256|192]x16 col, but, this doesn't leave much colour space, which is also very important in representing depth
I wonder whether the fillrate would be higher using the "Inter-Prop Bus" or DMA fed serial for this... Hmm... (This also depends on, I suppose, how much of the DMA buffer is consumed with incoming triangles)
That is interesting, although what I am discussing is in actuality true 3D (As far as anything on a 2D display can be 3D).
If I were able to rasterize (and the PropGFX draw) fast enough, I could probably acheive 2 to 4 times the triangles of the Prop native. On the other hand, the dsPICs would be able to do geometric transformations aswell, since they act on actual triangles (In fixed point). With enough effort, it should be possible to draw and manipulate quite large worlds, provided your careful with the polygon and pixel budget.
I was thinking that the video mode might be best as 256x192 interlaced (So draw 256x96 at 60fps). The drawing code wouldn't much object to that either.
What I'd really like to do with this is a space shooter where you & your enimies are 3D, traversing a large ship. At special points I'd drop the enemy budget so that you can swing through pipes, etc, into other sections. It would be really nice if I could have bosses be head on
Hi Owen, Nice to see you have some great ideas you want to do with our PropGFX As for fill rates, we have a mode, where it uses one or two ( not decided yet ) cogs less for rendering the sprites, instead, it uses them for graphics drawing, ie box, tri, line, can even do a horizontal fill for you, which would probably get filled before it receives the next command. although, I was going to have a draw-list buffer, where you send it a list of commands then send a command to say GO which would be faster, as it doesn't need to wait for next command.
Actually, when I consider the speed at which a line's coords can be generated, the "GPU" will probably be faster than the Prop. On the other hand, this gives me a nice prebuilt buffer, to tide over the sections where i'm calculating heavy math
I suppose one option is to use the came connector used to connect the Hybrid and the PropGFX, and have this sit in between. However, I now have another challenge: How do I perform communications between the GPU and the Hybrid? Do I add a second channel? Do I multiplex onto the PropGFX's bus? And if so how do I multiplex it?
You could use pins 24,25 or 26,27, and use the 8bits of the databus, as they're not used until you send it to PropGFX anyway.
and then have the Hybrid doing all the housework, sharing out work to the others.
OR have Hybrid connect to your stuff, which processes all the data, then spews it to PropGFX Lite to display, over a different pins. IE don't connect Hybrid directly to PropGFX ?
Just use the 10 bit bus and we can agree on a method of choosing which device gets control. We have two other control lines available on the Hybrid/Hydras bus so long as you don't need serial or USB. And maybe at a pich we could use the EEPROM data line too.
By what numbers are the pins referenced? It seems to be Prop pins according to the PropGFX Lite pinout here
What I want is some way to be informed that the host can say it wants to start talking to the GPU, and then issue GPU instructions, and then wait until the GPU has finished drawing, and switch back to the PropGFX, and issue some PropGFX instructions (EG: Sprite updates)
Does the PropGFX have any free pins, even if they're the, say, programming pins? I was thinking that perhaps that way they could be used to indicate that the PropGFX had recieved a "Switch to GPU" instruction, which would cause the GPU to gate the bus between the two, so it could firstly recieve it's own instructions, and secondly start spewing out it's own commands to the PropGFX. When the host had finished sending draw commands, it could just issue a "Wait for vid" command, and wait until the GPU had finished it's drawing.
If that were the case, all I'd need is some kind of R/W pin to indicate data direction I could feed into a 74x245 and the data passage would be almost completely effortless on my part
What are the handshaking lines on the PropGFX's bus?
As well as the 10m Bit databus we have two other pins available P30 & P31 these are used for programming the Lite from a Prop Plug or our own bespoke programmer. Once the programming is completed they are free for use but it is not beyond the realms of possibility that I could rejig the design to make a few extra i/o pins available. ( I have a few tweaks to make anyway)
How do you see the interaction between the Hybrid or other host micro and your GPU?
Check out the Hybrid manual for the Pin configurations.
The GPU would have a very small command set, quite simply
Tris count [word count * { byte colour, byte opts, 3 * {word x, y, z} } ] SetTransform { 16 transform values } SetZSort {on | off} Wait (Outputs 0xFF when done rendering all to the PropGFX. 0x00 till then) RelBus (releases the bus back to the PropGFX)
Hi Owen, I think what Coley was trying to say, was that the Hybrid's expansion port allows access to PropGFX Lite's 10 pins + 4 others, which you might be able to take advantage of, for your GPU. EG, where we have pinOK and CLK for Lite, you could use Hybrid pin 30,31 ( programming RS232 pins ) since they're no longer needed after bootup, and use those to talk to your GPU, like the LITE's pinOK and CLK. then you could still use the databus for your GPU, sending data from Hybrid, to GPU, wait for completion, then send updates to Lite and all will be happy.
Aah yes. That still leaves the question of how do I feed polygons into the GPU while the GPU is feeding lines to the PropGFX, however. Unless I were to pipe triangles via SPI, but that has bandwidth limitations...
Home
Calendar
Search
Register
Login
Print Thread
Report to Moderator
Logged
Private message
Site
WLM
