Diego's random questions and ramblings

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Diego's random questions and ramblings

Post by diegzumillo »

I have been feeling too spammy lately, with topic after topic of quick questions. So I decided to make one topic to rule them all. Unless it warrants a new topic any quick question I have I shall put it here. In fact, if anyone wants to borrow my topic for quick questions you are welcome to do so. If that happens we might want to change the Subject to something more general.

After I stopped playing with mode 8 I decided to try working with the "vanilla" (as in, the recommended mode for someone who is new to uzebox), AKA mode 3. So I made a mockup on aseprite (pixel art software) using uzebox's palette knowing full well implementing a scene like that would require some serious tweaking, but I went ahead anyway because the idea is to start with a full ambitious scene and start to trim it down until it fits.

Here is the initial mockup (pixel deformed because of the aspect ratio)
Image

As expected there are too many unique tiles in there but that's ok. It's a mockup and from that the next step would be to reproduce it using premade tiles and the characters would be sprites.

But I still wanted to make this scene fit so I started to paint entire regions of solid colors and crop the scene a little more until the number of unique tiles got small enough. But here's the thing, until now every time I compiled the code would complaint about overflow with warnings

Code: Select all

warning: overflow in implicit constant conversion [-Woverflow]
So I was surprised to learn that even after trimming it down until I got no more warnings, the execution still had some graphical artifacts. The black squares at the bottom seem to be missing tiles.
Image

I have no idea what limit is being broken here. Number of tiles on screen or number of unique tiles on this map?

So that was a question. Now a comment: I think 256 colors is way more than I will ever need with my pixely doodlings, so maybe I should check out mode 13, since it is similar to 3 but with a paletted mode. Hopefully there is something to gain when trading color freedom, right?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Diego's random questions and ramblings

Post by D3thAdd3r »

Not sure how many unique tiles are there, but in Mode 3 you can have 256-RAM_TILES_COUNT unique flash tiles on the screen(ignoring overlay). My guess is that turning ram tiles down fixes your immediate issue, but of course it pushes against sprites.
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Re: Diego's random questions and ramblings

Post by diegzumillo »

I just checked here and it has 238 unique tiles. I have been trying to understand ram tiles in the wiki. In this scene there are no sprites, is the sprite count taking room even without sprites? I tried decreasing dmax_sprites and increasing dram_tiles_count but that doesn't change anything.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Diego's random questions and ramblings

Post by Jubatian »

diegzumillo wrote: Mon Sep 17, 2018 2:21 amI just checked here and it has 238 unique tiles. I have been trying to understand ram tiles in the wiki. In this scene there are no sprites, is the sprite count taking room even without sprites? I tried decreasing dmax_sprites and increasing dram_tiles_count but that doesn't change anything.
So, what are those RAM tiles:

A typical Uzebox video mode renders tiles, you have a VRAM where every byte corresponds to a tile index, that is, you can have up to 256 tiles on a screen (normally), while this VRAM usually takes up to around 1K of RAM (more or less depending on the video mode's resolution and whether scrolling is enabled, which requires a larger VRAM). The tiles are 8x8, assuming Mode 3, they take 64 bytes each as they are 64 pixels, and it is a 8 bit mode.

Those tiles have to be served off from the ROM mostly, as there is no way to fit them in that little RAM the AVR has. However if all those tiles were served from ROM, there would be no way to realize sprites! Remember, there is no hardware assistance here, all is done by the CPU, and such a tiled mode offers the greatest achievable resolutions combined with the flexibility required for games.

To get moving objects, RAM tiles are needed, so there is some place where you can draw them. In most video modes the VRAM constrains you to 256 tiles at most. You have to decide where you split this range between ROM and RAM tiles. That's RAM_TILES_COUNT in Mode 3, for example if you set it 16, then there are 240 ROM tiles and 16 RAM tiles.

Sprites use these RAM tiles, in Mode 3, using its sprite engine, quite autonomously. The sprite engine takes care of that your sprites get rendered, by that behind the scenes it figures out which tiles the sprite covers, copies them off onto RAM tiles, draws the sprite graphics on top, and alters the VRAM so it shows these modified tiles. Then, before your user code would run again after a video frame, it restores the VRAM, so your code can't see this translation occurring.

Hope it makes things a bit cleaner for you. There is also a good article on the Wiki called Sprite Techniques, which describes some stuff in-depth regarding how you can optimize your game for this.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Diego's random questions and ramblings

Post by Jubatian »

diegzumillo wrote: Mon Sep 17, 2018 1:55 amSo that was a question. Now a comment: I think 256 colors is way more than I will ever need with my pixely doodlings, so maybe I should check out mode 13, since it is similar to 3 but with a paletted mode. Hopefully there is something to gain when trading color freedom, right?
You definitely could check it out, indeed!

The greatest advantage of Mode 13 is that it can have a lot more RAM tiles than Mode 3 as a RAM tile in Mode 13 is only 32 bytes. If you aim to have such large sprites, you will need this. However the mode is significantly slower than Mode 3, so probably you should plan with a narrow screen (such as 180 pixels or so tall). If going a bit lower in resolution is OK with you, there is also Mode 74 (1.5:1 pixel aspect ratio, 192 pixels wide), the mode Flight of a Dragon uses. Sprites in this mode are just as fast as Mode 3's. Mode 13's sprite performance can not be improved due to the technology of the mode.

It could be possible to make a video mode with Mode 3's resolution at 16 colors which could use Mode 74's sprite engine (so fast), but currently there is no such, not even as a prototype, only proof of concepts for its rendering loop.

By the way the concept art is very nice, hope those sprites could be animated later!
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Re: Diego's random questions and ramblings

Post by diegzumillo »

Jubatian wrote: Mon Sep 17, 2018 7:48 am So, what are those RAM tiles:
Thanks, Jubatian. That made things a lot clearer! I'm used to seeing the terms tiles and sprites as describing different things, I guess that is where my confusion started. So you set the number of ram tiles depending on how many moving things/sprites you want at any time. My little mockup test worked just fine after I adjusted that value. I was trying to fix it by increasing it instead of reducing it. Goes to show how half knowledge of something can be worse than no knowledge at all.

About mode 13 or 74. I really don't know which to start with now. Both sound like good alternatives! I guess I'll start with the one with more documentation and more games made so I can learn it quicker :mrgreen:
Jubatian wrote: Tue Sep 18, 2018 1:27 pm By the way the concept art is very nice, hope those sprites could be animated later!
Thanks! I'm actually super proud of that character on the right. It's from an old project of mine that never got off the ground. I was doing it on Unity at first then moved to Godot. I wanted to make a platformer on a grid; That is what I call it but people like to call these types of games "cinematic platformer", a term I detest. Games like Flashback and blackthorne are good examples. Prince of Persia is definitely the inspiration but I recently learned that PoP is actually not on a grid, completely blowing my mind.

Anyway, I made a bazillion of animations for it and I wish I could use all of them but probably won't be able to; the entire animation sheet for a single character alone would blow up uzebox's memory. After working on that project for a while I realized making these type of platformers is an absolute phenomenal amount of labor, so I shelved it. Now I'm adapting to something simpler for Uzebox! Let's see how far I can take it.

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

Re: Diego's random questions and ramblings

Post by Jubatian »

That's some beautiful animation, indeed!

Sure it would be tricky for the Uzebox, but not impossible! If you like crunching the bits, it may be a good challenge to get it in, it would be a very similar challenge like I faced with Flight of a Dragon, which incorporates many unusual techniques to fit a complex game in that 60K ROM + 4K RAM. The sprite engine in that game is very unconventional, it heavily reuses sprite components, arbitrarily assembling them to get the dragon's frames, so the entire dragon fits in some 6 kilobytes.

If you want something simpler on technology, and you are okay with using the SPI RAM expansion, you may choose Mode 748 instead. The sprites of this mode are fetched from the SPI RAM, so you can have a lot of them, and it is actually simpler to grasp than Mode 74 (Mode 74 also allows SPI RAM sprites, but with Mode 748, you could also add title screens, story images and a lot of other stuff utilizing the mode's flexibility in displaying data directly from the SPI RAM).

These modes don't have too many games. Mode 13 maybe none completed, but it is the most similar to Mode 3. Mode 74 has Flight of a Dragon and Stormforce. Mode 748 also has none yet, however it is based on Mode 74, actually simplifying it.

In several graphics editing software there are tricks to get unconventional pixel aspect ratios, I don't know if you were aware of this, if not, the Wiki has an article on this, how it can done with Gimp. I did Flight of a Dragon's pixel art using this.
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Re: Diego's random questions and ramblings

Post by diegzumillo »

Oh I don't think I'm competent enough a programmer to pull something like that off.

I thought about that spi expansion though. I'm not sure about how I feel about it, because there is no end to this path of expansions, and in this day and age no one uses uzebox for its raw computing power; we like the limitations. I also feel like too many variations of open source projects tend to weaken it. I feel like instinctively we need the concept of canonization everywhere, you know? At the same time a tiny expansion would really go a long way in making uzebox more interesting from a game designer perspective. I mean, limitation certainly helps creativity but too much limitation is not much fun either. If making anything that isn't a single screen game is a worthy challenge of a software engineer then there won't be many non single screen games ever. PLUS (and this is the last point) if it's simple to install, and the part is cheap, that would certainly help its case! (I have no idea how to install that)

Anyway, I'm sure this was discussed to death around here already.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Diego's random questions and ramblings

Post by Jubatian »

diegzumillo wrote: Wed Sep 19, 2018 2:54 pmI thought about that spi expansion though. I'm not sure about how I feel about it, (...)
SPI RAM wasn't much discussed, some like it, some not so much rather sticking with the single ATmega644 idea. However there are no games so far using it, which also makes it interesting: what could be pulled off with it?

If you like to design graphics, I would suggest taking this path, it will be more enjoyable for you as there is room to place that graphics, and it still offers a challenge with it being only 128K, and that it is a slow RAM. Otherwise I think I really pushed the limits with Flight of a Dragon (I really wanted to add more art in that, but it just didn't fit!). It is insanely difficult to do larger games as despite the SD card, the 4K RAM is a hard constraint, maybe Mode 52 or Mode 72 could be the best candidates for realizing rich games with sprites using SD data, and not SPI RAM.

Adding the chip itself is quite simple, it's just an 8 pin DIP, you may even piggy-back one onto any Uzebox without much difficulty.
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Re: Diego's random questions and ramblings

Post by diegzumillo »

The fact I never made a game in uzebox makes starting in uncharted waters very intimidating. But what the hell it sounds exciting. I'll give it shot.
Post Reply