3D texture mapping on Prop II
cgracey
Posts: 14,204
Here's a screenshot of the next Propeller's texture mapping in action.
Each cog has an instruction for doing Z-corrected texel lookup (from a texture stored in cog RAM),·color lookup (16 bits from the cog CLUT), pixel lighting for individual 5:5:5 R:G:B, and alpha blending with whatever pixel is in the D register at the time the PIXF instruction executes. The PIXF instruction does all the above, updates all deltas, and returns the blended pixel into the high word of D, while moving the previous high word into the low word,·so that a subsequent PIXF takes care of the other 16-bit pixel that was in D. Each PIXF takes 2 clocks, or just one clock if the CLUT returns 0 for transparency, in which case the original pixel in D is left in its original state, though moved to the high word. This video image was generated on the fly, with no buffering - just a little program that does two PIXF's followed by a WAITVID for every two pixels. Textures can be 1, 2, 4, or 8 bits, with X and Y dimensions of 2, 4, 8, 16, 32, 64, 128, or 256. Of course, if you try to do an 8-bit 256 x 256 texture, it will just wrap around the cog memory. You have to be reasonable.
In this image, there is a 4-bit 32 x 32 texture map with pixel lighting going from 100% to near 0% top to bottom and alpha blending with white going from 0% to near 100% left to right.
Thanks to Andre LaMothe for spending many hours with me on the phone until I understood what was needed for 3D texture mapping. In the end, it's pretty simple, but without Andre's help... forget it. He's already spent his life figuring out this stuff so that he's able to explain it to someone like me, and I don't have to go through the months (or maybe years) it would have taken me to get a handle on this, all·by myself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 4/20/2010 6:22:35 AM GMT
Each cog has an instruction for doing Z-corrected texel lookup (from a texture stored in cog RAM),·color lookup (16 bits from the cog CLUT), pixel lighting for individual 5:5:5 R:G:B, and alpha blending with whatever pixel is in the D register at the time the PIXF instruction executes. The PIXF instruction does all the above, updates all deltas, and returns the blended pixel into the high word of D, while moving the previous high word into the low word,·so that a subsequent PIXF takes care of the other 16-bit pixel that was in D. Each PIXF takes 2 clocks, or just one clock if the CLUT returns 0 for transparency, in which case the original pixel in D is left in its original state, though moved to the high word. This video image was generated on the fly, with no buffering - just a little program that does two PIXF's followed by a WAITVID for every two pixels. Textures can be 1, 2, 4, or 8 bits, with X and Y dimensions of 2, 4, 8, 16, 32, 64, 128, or 256. Of course, if you try to do an 8-bit 256 x 256 texture, it will just wrap around the cog memory. You have to be reasonable.
In this image, there is a 4-bit 32 x 32 texture map with pixel lighting going from 100% to near 0% top to bottom and alpha blending with white going from 0% to near 100% left to right.
Thanks to Andre LaMothe for spending many hours with me on the phone until I understood what was needed for 3D texture mapping. In the end, it's pretty simple, but without Andre's help... forget it. He's already spent his life figuring out this stuff so that he's able to explain it to someone like me, and I don't have to go through the months (or maybe years) it would have taken me to get a handle on this, all·by myself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 4/20/2010 6:22:35 AM GMT
1280 x 720 - 113K
Comments
That's fantastic [noparse]:)[/noparse] can't wait to get my mitts on this puppy! and no buffering that's cool [noparse]:D[/noparse] nice work with the blending too, and perspective correction!
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Would it be possible to actually do a 256x256 8bit texture by reading in from hub (or external) memory interleaved with the PIXF and WAITVID instructions? Or is it going to try to access cog memory addresses based on the texture dimensions such that you couldn't make it just loop over the same smaller chunk of cog memory that you fill in with new data as it's going?· Actually, if it supports texture wrapping, then you could achieve this via using a smaller texture and just reloading it with new data before it wraps.
Also, could you just store the results of the PIXF instruction instead of outputing it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I second Baggers comment!
Once again, (I predict) the Prop video capability will exceed RAM capacity. (that's a good thing)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/20/2010 8:51:40 AM GMT
That is rather a largish PropII I spy on the right of the pic LOL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
What is the highest resolution mode it can reasonably be used in? Will it be possible to do texture mapping on walls etc on a 320x240 15 bit color bitmap?
Really nice work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
But couldn't you throw your weight around and beg Chip to bump the chip up to a total of 1MB of built in RAM, despite the costs?
I mean, with one megabyte of RAM, let's see...we could do WQVGA (as wide screens are becoming the standard) at 400x240 times 2 bytes per pixel, at least approximately, if I understand chip right (5x5x5 plus a bit for something). That works out to 192,000 bytes, and let's multiply by two for double-buffering just for kicks which gets us up to 384,000. So, with a meg there'd be room for a program and data. I'd say 512K or 768K, but I have in mind an application that needs that just for the buffers. Sure, the chip shouldn't be designed around my particular application (for which, unfortunately, pins are also at a premium for and I/O expanders won't work). But 256K or 384K just doesn't seem to cut it. I sure hope Chip is working on a pleasant surprise in that respect as time passes. But maybe things can't work that way without going back to the proverbial square-one. Still, one meg, what a selling point! How flexible! Right now, the Prop I is essentially an Atari 800 or C64 on a chip. Great! But that's been done. Let's move up to an Amiga or whatever, something with some bite, so to speak and pun intended. On the other hand, an argument could be made for basically an 8-fold increase all around for the chip's power, which would mean just 256K, but these graphical things--and there WILL be graphical uses for the chip--eat up a lot of memory, right?
I recall once Chip talking about there being enough RAM to double buffer images (or the "video"). Even at only 320x240, double-buffered 2-byte pixels amounts to a total of 307,200 bytes. Yes, I know I'm greedy, but what's the point of having all the video capabilities if the chip's RAM is not going to allow convenient usage of them? Yes, I know, the standard answer will be that with 32 extra pins (a total of 64), an external memory chip can be added. But that complicates usage quite a bit. Wouldn't it be great if double-buffered WQVGA could be done in the chip? One chip? ONE CHIP! Sure, someone will say, then why not VGA or WVGA. That's true, there has to be a cut-off somewhere. But a meg doesn't seem like asking for the world. Would that nearly double the die size? Or more so? I don't know. I'm thinking out loud/asking. Would that significantly increase the package size? Maybe only a couple of·millimeters on a side at most, I'm·guessing (and guessing only). And costs? Well, it will be a special chip that can be conveniently applied to a wide variety of applications, without added complexity.
Yes, I'll be quite happy or at least reasonably happy with whatever comes out, and it's a real thrill to hear from our fearless leader. Thanks, Chip!· And sorry for opening up a can of worms. ·But real "fearlessness" might perhaps involve equipping the chip out-of-the-gate with enough RAM to really take advantage of its cool features. Oh...it's so easy to back-seat drive, Jim (the good angel said).· But, after all, how long will this chip be available? For a long time, right? And the world has changed a lot since the Prop I. And it will likely be a long time until the Prop III, and likely will never come out if greedy, reasonably ignorant people like me keep chiming in where they're not needed. Sorry about that. No, I don't want to see the Prop II delayed significantly, of course. Just hope that it's features, including the RAM can work together and be as flexible as possible. Even if people don't need the video memory, there will be uses for it. Of course it's okay to still have a soft spot for the fact that it can output NTSC/PAL, but connection to small displays, including wide ones should at least be considered. I mean, sure, it'll still be useful for generating standard-definition TV signals, and that's super-cool, even now, but the new chip should also go considerably beyond that, me thinks...hopes...muses.... Oh, well, I can dream. This is not intended as a rant, please don't misunderstand. Again, Parallax is doing great work. And the product-in-development seems pretty great, already, borderline fantastic, if not so. Okay, fantastic! (A/D, D/A, pull-ups/downs, etc.) Please don't stone me. Great work Chip/Parlallax. Apologies for the non-texture-mapping off-topic post, though memory is tangentially related to graphics. Ciao-for-now.
Post Edited (JRetSapDoog) : 4/20/2010 5:48:07 PM GMT
eg: Baggers rendering WOLF3D, on the Prop I, among other tricks not really envisioned as being possible when the video capability was originally realized.
The key here is dynamic display. That's cheap from a silicon perspective, yet capable. Full on double buffered bitmaps are what PCs do, not micros, but that's just me. With this video capability (assuming the known features so far), great displays are going to be possible at pretty good resolutions. It will just take some work to make good display engine economy.
So far, Prop II uses the same design ideas Prop I did, meaning the video will scale nicely as people really get their heads wrapped around the chip. I'm pleased at that, because I really like the software video idea. Over time, it continues to improve, where more dedicated things tend to top out.
External RAM is going to be a reality on Prop II, so the game is upped another few notches. Dynamic display, external RAM, fast COGs, with CLUTS, etc... is going to rock!
With the RAM that is on the chip, nice 1024x768 screens are going to be possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/20/2010 7:14:55 PM GMT
You are correct with Yours PIXEL/Memory calculations - BUT!!
If Chip implement RD/WR system I proposed it will be possible to have much more external memory to THAT.
And still have Pins to other things
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Update:· Oh, sorry, Potatohead; I somehow missed your follow-up post.· Thanks for the clarification.· Eh, I mean your expanding on the·nuances of what you probably already said well enough (except for those of us--me--that didn't think about it enough). Good points.· Thanks!
Post Edited (JRetSapDoog) : 4/20/2010 7:10:53 PM GMT
And I am sure I am not the only one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I really like the video approach. That coupled with the COGs, gives the chip a lot of potential! It's a PITA to get the core signals, buffering, sprites, and other display management elements in place, but once they are done, it kind of rocks! And, there isn't any waste really. IMHO, on Prop I, some video capability remains generally unexploited due to RAM and external memory throughput / pin issues. With the extra pins on a Prop II, this isn't going to be a big issue. The other big deal is being able to do way more computations on the fly. The waitvid loop on Prop I tops out somewhere around 3-500 horizontal pixels, depending on what device is being rendered too. That puts higher resolution displays, as well as some display types (like component) off the table, unless the chip is just doing mostly display.
The increased speed, and new features will mean 1 or 2 COG displays that will have very rich features, while being RAM lean. If somebody wants to push it using most all of the chip for display and I/O comms, some seriously good quality displays are going to be possible [noparse]:)[/noparse] And it won't cost a ton, and can be very flexible. That's the part I think is really sweet.
A quick look back at older video systems reveals the ones that had more built in "easy" features, topped out and stayed there early in their life cycle, requiring very significant hacks and tricks to exceed the original specs. The way the Prop was designed really put the design specs into the programmers hands, where all the little tradeoffs can be managed for the best use of everything involved. The systems that did that (and there were not many), continued to see improvements in capability over a very long time period. In the case of the Prop, that video functionality was generalized enough to be used for other things. The same appears to be true for Prop II, and that's really damn cool, just from a geek tech perspective, and a practical one. The CLUT table, will make for a much needed source of local COG storage, for example. That's the kind of thing that really sees good use over time, for a wide scope of tasks.
The extra compute power per pixel will mean easier to use video "kernels", offering features that are currently difficult, or expensive on the Prop I. In micro land, I really do think less is more. You won't hear me pushing for less RAM. That's not my point. Really, it's all about packing in as much RAM as can fit. From there, given the multi-processing way the Prop works, it's not a big stretch to provide killer video. I think that's almost always true, unless one is talking about a lot of RAM, and that amount of RAM would push the cost sweet spot away from the lower optimum, IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
If they're seriously looking at this, there's a definite point of critical mass, where you have a 3D engine that can use the early 3D formats or you don't. On the low side, creating content will be really difficult. When you're over a certain threshold, you can use existing content, level editors, 3d modeling software and so forth.
-phar
Sorry. stuck in a loop here.
http://www.youtube.com/watch?v=kjxI6vBG7wE
Live, it's glass-smooth, but youtube tends to conchunkulate things.
The software that did this for each visible scan line was just:
······· mov···· pairs,#256·········· 'ready for 512 pixels
:loop·· mov···· pixels,h7FFF7FFF···· 'set two 5:5:5 background pixels to WHITE
······· pixf··· pixels·············· 'alpha blend next texel into low-word pixel
······· pixf··· pixels·············· 'alpha blend next texel into high-word pixel
······· waitvid scale,pixels········ 'output two pixels
······· djnz··· pairs,#:loop········ 'loop until 512 pixels output
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Having thought about it a little bit, I'll bet you could put together something like an improved Doom engine pretty quickly. Rendering would be 3D, but do collision detection with a 2D map like Doom. So you wouldn't have to touch the renderer to upgrade it, just improve the collision detection.
-phar
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
if MicrocontrolledSeesVideo == true Excitement_level *= 1000000 if PropIIout == true MicrocontrolledSay(string("YEA!!!!!!!!!")) else MicrocontrolledSay(string("Drat!")) Excitement_Level /= 50000▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
h7FFF7FFF· long·· $7FFF7FFF
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
What is the "pixf" function? I do not believe that that is part of the current PASM command set.
Edit: Just read the above statement
Can we see some more code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
Post Edited (Rayman) : 4/21/2010 12:23:14 AM GMT
Nice video.
And simple ASM code to generate it.
I suppose that even other ASM will be that wise. That ones that handle Bytes/Words/Bits for all types of "State Machine" type Programing
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Bill
BTW: 384KB of SRAM takes a huge chunk of the silicon. Flash takes far less and ROM less still. But flash cannot be used like SRAM and all the chips out there have large flash but demonstrably smaller RAM. We are beginning to see some large RAM sizes appearing though and this also must have the capability of executing programs from it (not all RAM on microprocessors do). This is the flexibility we get with the Prop and I think this is often forgotten.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
experimenting with, we'd love to see it
I believe he's still working off of a 1,000+ pin Altera FPGA.