Go Down

Topic: The DHG - Dynamic Hi resolution Graphics driver (Read 1 time) previous topic - next topic


At the moment it only has 128 tiles so if you try to fill the screen, it wont work.
But a reasonable amount of text, sprites and gfx works really great.

I plan to try out your code soon. If the tiles are not being used, to they consume memory? I see great potential in a "Sprite Graphics" type system like this, for games without tons of background graphics. For instance, if a program was required to only use bitmap sprite data, stored in PROGMEM (too slow to use directly?), and the engine just kept an array of how many things it was displaying and where they were supposed to be drawn, it would free up a ton of memory.

I suspect PROGMEM might be too slow, so RAM would have to be allocated for the sprites that were in use. I might have eight bitmaps for an Asteroids ship, and display frame 1 at X,Y, using up only the RAM/overhead for that bitmap.

Interesting concept. I just started playing with Arduino video output last weekend, and have much to learn. (I am documenting my attempts to make a Pac-Man clone at www.subethasoftware.com)
Embedded Software Engineer
UNO | Leonardo | Due | Teensy | BASIC Stamp


IWould it be possible for the user to only allocate memory for tiles that are needed? Something like this:

The code would define the bitmap data for the sprites...

// 8x8 spaceship... A box because I am lazy.
#define SPACEBOXW 8
#define SPACEBOXW 8
PROGMEM const uint8_t spacebox[] = {

Then, assuming doing PROGMEM reads might be too slow for video, RAM would be allocated for that tile/sprite. Maybe a structure like this that could contain info on where the tile is supposed to be drawn, and information about the tile size:

typedef struct {
  uint8_t x, y;
  uint8_t w, h;
  uint8_t *dataPtr;

Then something like this (maybe hidden in a function to make it easier):

TILE spacebox;
// RAM to hold the copy of the sprite data
uint8_t spaceboxRam[sizeof(spacebox)];
// Copy PROGMEM data to RAM buffer
memcpy_PF(spaceboxRam, spacebox, sizeof(spacebox));
// Update tile object to know where RAM buffer is.
spacebox.dataPtr = spaceBoxRam;
spacebox.x = 255; // Maybe 255 means "do not display"
spacebox.y = 255;

Then some interface to add/remove it to the stuff the video engine is drawing on the screen.


Then in the code loop, the engine would go through all the tiles that have been added and display them. The use would do stuff to move them just by modifying the object:

spacebox.x = 50;
spacebox.y = 50;

For a game, such as Space Invaders, where there are five rows of eleven types of aliens, there would be RAM for five tiles buffers allocated, and there would be 55 (11x5) TILE structures to track each invader.

For animation, the tile would just have the pointer changed to point to the next frame. (A clever function could be written to let the user pass in an array of frames and have it actually handle the animation directly.)

spacebox.dataPtr = spaceboxRam2;

(I would be using an array of frames, most likely, and be setting them to something like spaceboxRam[framNum]);

NOTE: This would have to be done between interrupts so it didn't mess anything up, I suspect?

Just some quick thoughts. Displaying full screens of text this would wouldn't necessarily be practical, but it might be great for games. I have about 220 bytes free for my Pac-Man demo, using the low resolution of TVout. It would be fun to see what could be done in an environment with more RAM to play with, and higher resolution to boot!
Embedded Software Engineer
UNO | Leonardo | Due | Teensy | BASIC Stamp


Feb 14, 2014, 06:31 pm Last Edit: Feb 14, 2014, 06:56 pm by janost Reason: 1
No. PROGMEM is not slow but it kind of defeats the purpose of dynamic allocation.
With progmem it becomes ROM tiled or what is in everyday called a char-rom :)
My VideoBlaster platform runs with ROMtiles or text chars.

Your are in charge of your own program so if it doesn't require all 128 tiles then just lower the amount.
Change the size of DHGmem and lower the test for maxtiles in the Dpset function and it should work.

The thing with sprites (like the DHG takes care of) is that, say an 8x8 sprite, takes a single tile when at a position multiple of 8.
Once its moved a single pixel to the left or down it takes 2 or 4 tiles because of the boundary.

There isn't much time in the pixelshifting for or-ing pixels so the data really needs to be prepared on a linebasis.
And then there isn't time to prepare the next line.

For your space invaders example, you poke out a number of fixed tilespointers in videomem.
Then you animate them by changing data directly in the DHGmem.

Go Up