Where's the SetPixel and GetPixel graphics functions?
Dennis Ferron
Posts: 480
I thought I understood it after the last discussion, but the tile-based raster system used by the tv.spin and graphics.spin object is still making me pull my hair out. I really HATE the way you guys have got your pixels laid out in memory - no matter how many times I go over it, I don't grasp the finer points of how it works. I realize it allows some neat tricks for pointing tiles to the same memory, but all I want to do is treat the whole screen like one big bit-canvas, tiles be damned. The graphics object does some incredible things which I don't need at the moment, yet where is the GetPixel function? There's a plot() function to set a pixel, but I cannot find its sister function - I see no way to get a pixel color based on coordinates.
What I'm trying to do is write an "ant farm" game in the style of QBASIC games which use the colors of the pixels on the screen to tell what's where. For the game I'm working on each pixel on the screen is potentially a "grain of sand" based on its color. Of course if you draw over the screen you loose your play area information, but this way I can have as many "cells" in the game as there are pixels on the screen, without extra memory overhead. I'm trying to access the screen memory directly, as I used to with CGA and EGA screens, which are not tiled so you can treat them as giant bitmaps.
I'm seriously considering writing a non-tiled tv.spin just to get rid of the tiles....
Right now I'm still trying to make tv.spin & graphics.spin work for it, but I'm hung up on GetPixel/SetPixel. I think I'm calculating the GetPixelIndex wrong:
What I'm trying to do is write an "ant farm" game in the style of QBASIC games which use the colors of the pixels on the screen to tell what's where. For the game I'm working on each pixel on the screen is potentially a "grain of sand" based on its color. Of course if you draw over the screen you loose your play area information, but this way I can have as many "cells" in the game as there are pixels on the screen, without extra memory overhead. I'm trying to access the screen memory directly, as I used to with CGA and EGA screens, which are not tiled so you can treat them as giant bitmaps.
I'm seriously considering writing a non-tiled tv.spin just to get rid of the tiles....
Right now I'm still trying to make tv.spin & graphics.spin work for it, but I'm hung up on GetPixel/SetPixel. I think I'm calculating the GetPixelIndex wrong:
PRI GetPixelIndex(px, py) : pixel_index pixel_index := (px & $F0) * y_tiles + py PRI GetPixel(px, py) : pixel_color pixel_color := display[noparse][[/noparse]GetPixelIndex(px, py)] pixel_color >>= GetPixelShift(px) pixel_color &= %11 PRI SetPixel(px, py, pixel_color) | index, old_color, shift_amount index := GetPixelIndex(px, py) old_color := display[noparse][[/noparse]index] shift_amount := GetPixelShift(px) old_color &= !(%11 << shift_amount) old_color |= (pixel_color << shift_amount) display[noparse][[/noparse]index] := old_color PRI GetPixelShift(px) : shift_amount shift_amount := (px & %1111) << 1
Comments
gr.plot(x,y)
You also will want
gr.colorthick(0-3, x) where x is thickness of pixel. (might have that backwards)
The problem with get pixel is that the current graphics drivers want to paint the screen each time, then copy it to a display page. It's not easy, without using some sort of state flag, to know the state of the display. It's also problematic in that the entire display is redrawn each time. Both of these conditions are not good for the ant farm game.
You might consider pointing the screen display code to the same bitmap you are drawing on, then don't do the copy screen part, and only using the clear screen command when it makes sense within the context of your game.
(I'm not on my prop enabled machine at the moment --sorry)
Look at the graphics demo.
At the top, it starts the TV driver and points it to the display bitmap. Also it points the graphics drawing code to another drawing bitmap. You want both pieces of code to point to the same bitmap space.
Follow the code down through the loop and you will see where the draw bitmap is copied to the display bitmap. You don't want this to happen. Either.
The result is a double buffered display to eliminate flicker. The result of all your graphics commands will be shown in one quick change, thus cutting down on flicker. The motion in the graphics demo is really just drawing everything on the screen, showing it while the next frame of motion is being drawn, then swapping the two quickly. The prop is powerful enough to just blast through the commands one frame at a time, thus the double buffer makes sense for a lot of displays.
For an ant farm game, you really want a single buffered display. That way, your get pixel code can depend on the bitmap being static. Most computers have this kind of display by default, and you code things like double buffer yourself.
IMHO, this is totally possible with the current tiled screen drivers, it's just gonna require you to redefine some things, and omit some commands used in the sample code.
You can reverse engineer the plot pixel command too. It's actually written in assembly, with the other cool commands leveraging it for speed. Again, using the graphics demo, look at the things it starts. One is the TV driver, one the mouse, the remaning one is the code that handles drawing the graphics primitives. Examine this to locate the gr.plot code. You should be able to work out the screen mapping from that, to code a solid get pixel routine.
Why?
I find the Propeller's approach rather purposeful.
If the approach doesn't correspond with your design goals, try ImageJ, by Wayne Rasband at NIH. ImageJ is fully cross-platformed and allows you to address pixels from macros, plugins or by modifying the public domain sources...all fully documented. http://rsb.info.nih.gov/ij/
What ImageJ doesn't allow you to do very easily is... anything else.
If I were you, I would talk to Wayne and pose him the question... if you wanted to output some signals to the Propeller based on your analysis of pixels... what would you have to do?
Or if you are just interested in displaying some kind of result... what would you have to do to get ImageJ to accept signals and create displays as a result of the values sent from your Propeller to ImageJ?
Wayne is a genius... and he will answer your questions completely.
The direct answer to your stated question about the Propeller would no doubt involve references to the total amount of memory available... memory which is available in a timely manner. It turns out that the total memory required for an image is a described by Shannon's relation ... -k*sum pi *log2(pi), where pi is the frequency of each sub population taken in turn and summated through i and k is a scalar derived from various dimensions. Since we are talking hub ram here... we are talking aout little bitty images or larger images that are cleverly encoded. In the absence of encoding, the available RAM limits both the bit depth and the image dimensions. One of the reasons that you are pulling your hair out is that you aren't trying to solve the same encoding problem that the Propeller's designers were trying to solve. If you want a trivial image... a few bits per pixel and not very many pixels... then you can probably talk someone into creating an object to convert handicapped bitmaps into noiseless video.
Please explain what you are trying to do, give a hint as to why you are trying to do it and if you talk to Wayne... keep us in the loop.
Thanks,
Rich
After doing some thinking about this, using the double buffer screen is not such a bad thing. The key is not clearing the drawing screen every iteration through the loop. If you do that, you are left with only having to write your get_pixel subroutine.
Right now it happens like this: (in graphics_demo.spin)
'clear bitmap gr.clear(do a bunch of drawing to the drawing bitmap)
(gr.line, etc...)
'copy bitmap to display gr.copy(display_base)(then display the results)
So, your game loop should only do a clear, when it makes sense to do so. Point your new get_pixel routine at the drawing bitmap as it will hold the pixel values necessary for the game state to be stored on the screen instead of in an array.
You want to clear the screen to start the game, then iterate the game state, copy the drawing bitmap to the display when the game state changes, then continue to loop the game state. Clear the screen for a new game.
In the graphics.spin program, it uses a command queue to draw things. Essentially it's always running, waiting for new graphics commands to hit the running program. When it sees one, it branches to the actual code, does it's thing, then continues to loop.
There is not much space in this process, so you will need to omit some commands to make room for get_pixel, or start another cog and use the same kind of structure, or put the get_pixel into your game code. (This would be slow, but might be ok. Mike Green actually recommended this be done in spin and he's probably right!)
Your screen calculation code is here in graphics.spin (I've got the relevant code here, for clarity.)
PUB plot(x, y) '' Plot point '' '' x,y - point setcommand(_plot, @x) ' Plot pixel at px,py ' plotd mov px,dx 'set px,py to dx,dy mov py,dy plotp tjnz pwidth,#wplot 'if width > 0, do wide plot mov t1,px 'compute pixel mask shl t1,#1 mov mask0,#%11 shl mask0,t1 shr t1,#5 cmp t1,xlongs wc 'if x or y out of bounds, exit if_c cmp py,ylongs wc if_nc jmp #plotp_ret mov bits0,pcolor 'compute pixel bits and bits0,mask0 shl t1,#1 'get address of pixel long add t1,basesptr mov t2,py rdword t1,t1 shl t2,#2 add t1,t2 rdlong t2,t1 'write pixel andn t2,mask0 or t2,bits0 wrlong t2,t1 plotp_ret plotd_ret retI was going to do exactly this before having to take some time to handle family issues. Should be no big deal to work through how a pixel is plotted and read a value instead of write one. My plan was to omit the text stuff, leaving plenty of room for more pixel related stuff.
For this kind of game, you can use a lower resolution to get bigger pixels too. Tinker with the horizontal scale and the number of tiles parameters to get lower resolutions. If you want thicker vertical pixels, you can change the vertical scale parameter, but you need to cut the number of vertical tiles down by the number of added vertical lines of height, or the display will get hosed. I had the best luck doing this first, then verifying the display area was half the size, then changing the vertical scale parameter in tvparams.
For the horizontal pixel changes, you want to set the number of tiles, then adjust the horizontal scale parameter to have them fill the screen. Again, cutting the tiles first, then tweaking the scale is easiest as you can see the results.
I was able to get resolutions that ranged from 64 pixels horizontally and 1 to 4 vertical scanlines high with no problem. The driver plotted the pixels correctly at all resolutions with no changes! Actually, that's not totally true. The core libraries that came with my initial download of the prop tool 1.0 had some problems with this. The HYDRA ones didn't and I've not checked the newest parallax library code.
Post Edited (potatohead) : 2/20/2007 5:48:06 PM GMT
First off I want to say sorry about the frustrated tone of my previous post - nothing personal against the person/people who designed the graphics memory layout for the tv/graphics objects. It's just not a good fit for the way I'm trying to use it. I think I will actually roll a custom tv driver, because that will give me the opportunity to integrate the mouse cursor driver into the tv driver - I can make the tv driver "overlay" the mouse cursor as it's spitting out the TV signal, and never have to actually "draw" the mouse cursor on video memory (which would obscure what is underneath the mouse cursor, which is a problem if you are using a single video page and the game uses the pixel data and can't tolerate pixels being obscured.) While I'm at it, I might as well make it a hybrid display that can overlay any number of sprites on the screen on top of the bitmap, without actually drawing them to the video memory - it would first check if the pixel overlaps where a sprite would be; if it does, it would draw the sprite pixel, if not, it would draw the background pixel. That would allow me to have moving sprites and a mostly static sand background, without the chance of the sprites accidently erasing sand pixels.
rjo_, I think you misunderstood what I meant by treating the screen as a "bitmap". When I say "bitmap" what I mean is "raster" - that is, the raw pixel memory being displayed to the tv. It has nothing to do with image files, such as BMP or GIF files. It has nothing at all to do with graphics files, or with sending signals to or from a PC. Thank you for your kind suggestion, but I really don't think ImageJ running on a desktop computer would help me draw graphics on the Propeller. Forgive me if I am wrong but I get the impression that you believe the PC is sending data to the Propeller when graphics are being drawn - like a USB-TV adapter. It's not - when a Propeller is generating graphics, though it may remain hooked up by the USB cable to the computer, it is the Propeller by itself and only the Propeller that is actually generating the graphics on the tv; the PC is not normally involved in any way.
So when you say I might be able to talk someone into writing an "object" to convert bitmaps to tv signals for me, because of the context I'm not sure if you meant a spin object or an ImageJ object. I wrote the above paragraph assuming you meant I should have an ImageJ object, and I was explaining why that wouldn't work for a Propeller application. If you actually mean a Spin object, then ignore my last paragraph. As for getting someone to write a non-tiled, raster-based TV Spin object, there's really not a lot of difference between the way the tv.spin object works now and the way it would work non-tiled. You would simply remove the assembly statements that point to the next tile after each 32-bit pixel group, and replace it with code that simply increments the pointer to the next 32 bit value - because the entire line of pixels is laid out sequentially, so there is no jumping around. It would be a very small surgery (or lobotomy?) and then you could use the rest of the TV object as it is. (Well you might have to account for interlacing at the end of each line, but that is not hard.) The real issue is that then the graphics.spin object won't know how to draw on the raster, so you would have to also roll your own graphics drawing object.
As for Shannon's equation, I must admit it's over my head, but don't you think that's a bit of a bigger "gun" to bring out than what I need for this situation? Remember, I'm not talking about compressed graphics, I'm talking about raw rectangles with no compression of any kind. True, there is a memory constraint here, but my point is that if you are using the whole screen, it's the same amount of data whether you lay it out in lots of little rectangles (tiles) or all in one big block (raster). If you have 256x192 pixels, and you aren't pointing any of them at the same tile location, it's 49,152 pixels regardless of whether it's laid out as 16x12 tiles of 16x16 or as one block of 256x192. You don't need sums or logs or pi's to calculate that; all you need is a four-function calculator:
256x192 = 49512
(16x12)x(16x16)=49512
The only thing that you can fudge is how many bits you use per pixel (as you alluded to in your reply). Again, though, that doesn't involve Shannon's equation, it only involves multiplication. The "normal" graphics format uses 2 bits per pixel, yielding 4 colors. This requires 98,304 bits, or 12,288 bytes:
256x192x2 = 98,304
98,304 / 8 = 12,288
So a raster-based display with all the pixels of a line laid out sequentially takes up 12KB, which is exactly the same amount the tiled display of the graphics demo uses for a tiled video page. In reality the raster display actually uses less memory than the tiled one because it doesn't need the 16x12 tile pointer array, and it doesn't need 64 palette entries because I would use the same palette for the whole screen.
There is another benefit to changing tv.spin to be non-tiled - while I'm at it, it would be trivial to make it act like the Mode-X video mode that a lot of PC games used. The way that works is that you allocate an array in RAM that is taller and wider than the size of your actual display - it has a border of pixels around the displayed portion which is present in RAM but is not visible on the screen. The point of doing that is that then you can think of your visible portion as a rectangle that you can move around within the larger rectangle in RAM. Then you can scroll the background simply by changing the display origin - you don't need to do any blitting. The only drawing you actually do is in the small strip that is not visible. You can even make the display wrap around so that you can scroll past the edge of the available rectangle and it will wrap around to the other side, so that you can continously scroll and never have to draw more than the edge that is offscreen.
You might reconsider omitting the tiles for color mapping. Some of the color values are used to generate sync signals! It's probably easier to just omit the need for the screen array, since linear addressing would be used. One added bonus would be the ability to have different color maps for the display. Even though the linear addressing would not match up with specific tiles, it still would be handy for scores and other elements where a bit of extra color would add to the presentation.
Post Edited (potatohead) : 2/20/2007 6:25:45 PM GMT
One thing comes to mind and that is the display list. The Atari computers had this capability. It allowed one to divide the screen into regions vertically (and horizontally in some cases with timing). On the prop, instead of changing the graphics display, maybe assigning colors per scan line makes some sense?
IMHO the tiles would be better overall for a larger set of displays, but you seem to have it out for the tiles. So, nuke 'em!
BTW: No worries about your post. I feel for you man. This chip will drive me from feeling really good to just annoyed to the max in one day! That means it's something worth interacting with, IMHO.
Andre'
For the record I do think the code in the tv and graphics objects is top-notch. For what they do the tv driver and graphics objects are great. It takes some real genius to get something to be simple, robust, and general purpose all at the same time, because you're not just solving one problem, you're solving many problems many people might want to have. Not many programmers could pull that off.
Andre, are all the Hydra game demos sprite based? Because I think what I have here, being different, may be good for different types of games than what sprite engines are generally good for. This non-tiled driver would not be great for games with scrolling or lots of motion (unless I implement the "Mode-X emulation") but it could be good for other kinds of games that have lots of fine detail, non-repeating detail, like a hedge maze or "comic book drawing" graphics, which wouldn't tile well.
What you have could be called "Femto-Postscript"
I wouldn't want you to do a lot of work and end up getting yourself sued.
I don't think anyone would care, right now. But in a few years... who knows?
I have a new idea for games.. and I have prior art for all of it... but it won't be practical until we have a little more RAM available. At that point I would take it to the Hydra folks.
Rich