Coop game development

This forum is for artists to post their music and graphics or discuss artistic matters that could be used in Uzebox games.
Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Re: Coop game development

Post by Trihook » Sun Jun 17, 2018 12:12 pm

I'm not sure how all this works, so I made a theoretical mode similar to gameboy color specs, so please tell me is this how uzebox works.

VRAM: 4096 bytes

Resolution:
160x144 px resolution
20x18 tile resolution (1 tile is 8x8px)
360 tiles on screen at once

Tiles:
1 byte per tile for palette, flipping, priority:
4 bits (16 palettes), 1 bit for inverting colors, 1 bit for horizontal invert, 1 bit for vertical invert, 1 bit (priority draw flag) = 1 byte for color, palette and draw priority
Draw priority is a flag that can be set so the tile is drawn over sprites.
2048 bytes for pixel data in the 256 tile tileset (256 tiles * 8 bytes)
360 bytes for each tile in the screen

Palette:
3 bytes per color (RGB values)
32 palettes in total = 96 bytes
16 palettes are for tiles and 16 for sprites

Sprites:
1 byte for palette, flipping and rotation:
4 bits (16 palettes), 1 bit for horizontal invert, 1 bit for vertical invert, 1 bit for rotate 90°cw, 1 bit for rotate 90°ccw
8 sprites is 8 bytes

Since sprites use 4 colors, they need 2 bits per pixel. One sprite is thus 16 bytes
1584 bytes for pixel data in the 99 tileset (99 * 16 bytes)

2048 + 360 + 96 + 8 + 1584 = 4096 bytes

What actually needs to be in the VRAM, how much can one swap from ram to vram per frame and what am I doing wrong here?

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Coop game development

Post by Jubatian » Sun Jun 17, 2018 1:01 pm

Trihook wrote:
Sun Jun 17, 2018 12:12 pm
(...) and what am I doing wrong here?
Several things, actually :D

The simplest is probably trying to imagine it like you had to actually code this video mode on a normal PC, just in ordinary C or whatever language you are proficient with. How complex would it end up being? If quite complex, then it wouldn't work on the Uzebox.

The Uzebox generates graphics line by line, by processing rather ordinary code in that regard that it does just what processors are doing, executing instructions. There is no hardware assistance, the cycles per pixel figures actually mean that the processor has to send a pixel value to an output port this frequent when generating graphics. So for example at 5 cycles per pixel, the processor does 4 operations, then in the fifth, sends a pixel to the port. All the graphics mode can do has to be done in the remaining operations, including reading pixel data.

Now just try to decode an 1 bit per pixel tile in C (or any other programming language), applying palette data it to get the actual pixel values, and you will see where this is going. It isn't anything simple.

The Uzebox palette is a simple resistor digital-analog converter, which provides a fixed BBGGGRRR 8 bit palette (so 2 bits for blue, 3 bits for green and 3 bits for red). You can not have more colors, but usually, especially with attribute mode art, this shouldn't be a problem.

The 4 KBytes RAM is not VRAM, it is literally all the RAM the microcontroller has in which everything must fit (including game logic, audio processing and other stuff). Typically games use slightly above 3 KBytes for graphics. Usually graphics data comes from the following sources:
  • Background tiles: directly from the ROM (so it doesn't take precious RAM).
  • Sprite images: from ROM.
  • VRAM: in RAM, typically slightly below 1 KByte, depends on the count of tiles on screen.
  • Sprite blitting: Often up to about 2 KBytes of RAM.
Sprite blitting is what I mentioned earlier: the background data is taken directly from the ROM (not modifiable). To draw sprites over it, parts of the ROM has to be copied away so the sprite image can be drawn over it. In Mode 3 (8 bits per pixel), reserving 2 KBytes for the sprite blitter gives 32 tiles, so you can cover up to 32 background tiles with 8x8 sprites (so it is 8 totally free moving sprites). Mode 52 (2 bits per pixel) gives you 32 sprite blitter tiles in just 512 bytes of RAM. That means you have extra room in RAM for example for color attributes.

Hope it wasn't too intimidating, just tried to explain some of the innards without getting too much involved.

Some of your mockups, especially this one would mostly work well with Mode 52, it seems like you mostly use single attribute against a black background. Then you can use 3 color sprites on it of which one of the colors is black (the same as the background, while the free to select color is transparent on the sprites).

160x144 might work if you are okay with a small viewport within the display (as the pixel height can not be changed, and there are up to 224 visible pixel rows). Tricky, but might be doable (with square pixels, coding technique to get this done is the tricky part), and you will get lots of CPU time to spare with that (there is a longer time between frames). What might be worth to be tried at this resolution is an ordinary 4 bits per pixel video mode (the trick here is that 4 bits per pixel is not possible for near 1:1 pixel aspect ratio, but you need only 160 pixels horizontally, which may allow precalculating lines partially).

Trihook
Posts: 6
Joined: Fri Jun 15, 2018 9:33 pm

Re: Coop game development

Post by Trihook » Sun Jun 17, 2018 3:45 pm

Ugh, doesn't sound too encouraging =S

Dunno, I'll rethink my approach, when time permits I might come back with some mockups that are specifically made for the listed modes. I'll do a rework of l4rry's game and that will probably be enough time and experience to come up with something better suited for the system. Thank you for all the info and your time, it is appreciated.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Coop game development

Post by Jubatian » Sun Jun 17, 2018 5:09 pm

Trihook wrote:
Sun Jun 17, 2018 3:45 pm
Ugh, doesn't sound too encouraging =S
Eh, all we have is an 8 bit micro to do it all, after all :lol:

Based on your mockups, I would recommend Mode 52, if you need further info on this mode (as it is still an experimental one), just ask. Larry's Iros uses Mode 3, so if you help him, you will see what most of the games here are using.

(The black & white mockup looks particularly nice by the way, you handle shapes well in so few pixels! Mode 52 may seem to be an overkill for such usage, however sprites need 2 colors + transparency even there, requiring 2 bits per pixel for storage, so maybe an overkill, but not by much).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Coop game development

Post by D3thAdd3r » Tue Jun 19, 2018 12:41 am

For me, I sometimes build full concepts from the tiles, place sprites, items, etc. to get something that looks like it was a screenshot of the game running. Basically the most "intense" scenario that can happen in the imagined game. If you have that(following normal 8x8 tile rules), it is easy to apply counting to unique tiles, sprite limits, etc. and you can be sure what video modes would work.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest