Mode 72 development

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

I believe I know the answer, but you can still use any arbitrary 3 colors for any individual sprite correct? I decided I am going to use this mode right now(because it blows my mind away..literally awesome), and pretty sure I can finish the planned game rapidly within the next week. So long as that is true, it is the perfect mode for it. Also I guess the demo doesn't prove either way, but is there any issues with overlapping sprites? Perhaps these questions have been answered before in this thread, but this thing has really progressed and changed since the initial post it seems, for the better of course 8-) Just want to make sure what I am getting into here. If I had any suggestions to make, it would just be that the demo might show sprites with different sets of 3 colors and also overlapping so that all that is apparent just by looking at it.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

D3thAdd3r wrote: Tue Dec 19, 2017 10:49 pm I believe I know the answer, but you can still use any arbitrary 3 colors for any individual sprite correct? I decided I am going to use this mode right now(because it blows my mind away..literally awesome), and pretty sure I can finish the planned game rapidly within the next week. So long as that is true, it is the perfect mode for it. Also I guess the demo doesn't prove either way, but is there any issues with overlapping sprites? Perhaps these questions have been answered before in this thread, but this thing has really progressed and changed since the initial post it seems, for the better of course 8-) Just want to make sure what I am getting into here. If I had any suggestions to make, it would just be that the demo might show sprites with different sets of 3 colors and also overlapping so that all that is apparent just by looking at it.
These work! I mean, should, unless there is still a bug anywhere in the code :) All sprites can have any set of 3 colors, and they overlap just fine, Sprite 0 being the highest priority, and Bullet 0 the lowest (you can see the rightmost sprites overlapping the bottom of the zigzag). Contrary to Mode 2 this has a real line buffer (Mode 2 is partial and does transparency comparisons during the display section, that's why overlapping doesn't work there), so there are no such issues like there.

For documentation, look in the source files, everything should be described on the top of those (like in Mode 74), but playing around with the demo is also fine. For now rather avoid the Wiki as it describes the old Mode 72 behavior (I will rewrite it when I get most of this completed).

EDIT: I added new sprite modes, Mode 3 and Mode 4 may be interesting for loading data into them from SD card such as logos. Mode 4 is particularly tailored for such usage having 120 pixels horizontal coverage while being set up to be capable to mirror (so a 60px wide sprite can be mirrored to produce the other half, useful for displaying symmetric stuff with half the RAM requirement).
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Hey, I'm looking into using this mode for a tower defense game. Is there a reason why bullets render behind the other sprites instead of on top of them? What do you think about bringing them to the highest priority by default?
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Hi, I'm trying to build the source for your mode 72 branch. After installing the latest WinAVR (20100110) and compiling mostly everything else I then ran the following commands to build the mode72 example from a windows 10 powershell which produced the error:

Code: Select all

PS \uzebox\kernel\videoMode72\examples\m72demo> make
mkdir _bin_
mkdir _obj_
mkdir _dep_
avr-gcc -I"../../../../kernel" -mmcu=atmega644 -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=28636360UL -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -MD -MP -MT uzeboxVideoEngineCore.o -MF _dep_/uzeboxVideoEngineCore.o.d -DVIDEO_MODE=72 -DSOUND_MIXER=MIXER_TYPE_VSYNC -DM72_SPRITE_MODES=0x0001 -x assembler-with-cpp -Wa,-gdwarf2 -c ../../../../kernel/uzeboxVideoEngineCore.s -o _obj_/uzeboxVideoEngineCore.o
../../../../kernel/videoMode72/videoMode72.s: Assembler messages:
../../../../kernel/videoMode72/videoMode72.s:1913: Error: constant value required
../../../../kernel/videoMode72/videoMode72.s:1913: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72.s:1943: Error: constant value required
../../../../kernel/videoMode72/videoMode72.s:1943: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1011: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1011: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1045: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1045: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1060: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1060: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1094: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1094: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1109: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1109: Error: register r24, r26, r28 or r30 required
../../../../kernel/videoMode72/videoMode72_sp0.s:1147: Error: constant value required
../../../../kernel/videoMode72/videoMode72_sp0.s:1147: Error: register r24, r26, r28 or r30 required
make: *** [_obj_/uzeboxVideoEngineCore.o] Error 1
It seems like I might have the wrong version of an assembler? Any ideas?

EDIT: I thought I would look up the lines of code which are producing errors. It seems in each case you are doing something "unofficial", for example on like 1913 you are storing a constant into Z using sbiw. However, according to the AVR documentation for that instruction:

Code: Select all

Syntax:          Operands:                       Program Counter:
SBIW Rd+1:Rd,K   d ∈ {24,26,28,30}, 0 ≤ K ≤ 63   PC ← PC + 1
you are only officially allowed to use the following destination combinations:

R25:R24
R27:R26
R29:R28
R31:R30

You could kind of force it to compile using Z by writing SBIW ZL, 2 as is done elseware in your asm (I don't really understand this style), but one of the above should be used instead. But because you seem to have a common pattern of using eg. ZL I made a pull request which updates the instructions so mode72 builds in winAVR / gcc-avr here: https://github.com/Jubatian/uzebox/pull/2 later on if you wanted to fix the many places up to be closer to the AVR documentation, it should be easier after this change.
Last edited by rocifier on Fri Mar 16, 2018 10:59 am, edited 1 time in total.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Mode 72 development

Post by CunningFellow »

It might be something about lower case s versus upper case S for the file name.

the constants for register names get missed or something with the wrong case in some operating systems or something else from my frail old memory.

I know I had a problem like that in the past and had to use a different case for the file extension. Can't 100% remember what it is. I'll look through my stuff and try find it.
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

The filename was the first thought I had, but the file isnt using any #includes which is usually the problem that happens from using lowercase s when it doesn't run the C pre-processor and treats the #include as a comment, messing up the line numbers. Anyway, I've updated my comment above to include a pull request.. it all assembles for me now. Please let me know if that works for you guys too.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

I dunno why my compiler takes in 'Z' (which is also avr-gcc, just on Linux), it should be 'ZL', so what you did is the right fix. I just keep making this mistake since sbiw and similar instructions are word instructions, so truly you affect 'Z' even though you have to use the lower half in these instructions.

No, the extension is not a problem, I purposely use the appropriate parameters for the compiler in the Makefile to enforce using the C preprocessor. The kernel does that, too, so the appropriate style is this (keeping consistent with existing Uzebox codebase): use lowercase extension, and use the parameter.
rocifier wrote: Fri Mar 16, 2018 3:33 amIs there a reason why bullets render behind the other sprites instead of on top of them? What do you think about bringing them to the highest priority by default?
Yes, the sprite code is fixed, the sprites render in the order they occur within the code. I could only lay them out reasonably well by having the bullets first, the sprites last. I might be able to do a sprite mode which does the inverse, but it requires manually doing all the code (look into the sprite modes to see what I mean). For now I would suggest you to start with the sprite mode matching the best your intentions, then later I might be able to do one fitting your game proper.

Another note: I will likely make a change to the text parts, to use the same format like Mode 40 (now the format of the font is different). You may create an own font, no problem, just be prepared then that you might need to re-generate it later using Mode 40's generator.
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Alright sweet. Hey I'm trying to plan out a mockup for my game (I'll share it on my tower defense thread in the Games category), and just wondering about the tiles in this mode. What do you mean by "code tiles"? What are the limitations around this? So far I know it's 8x8 tiles of up to 16 colors. Do you think the mode could be modified to use 16x16 tiles? How many unique tiles could I use? Are the tiles in RAM?
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

rocifier wrote: Sat Mar 17, 2018 6:42 am(...) and just wondering about the tiles in this mode. What do you mean by "code tiles"? What are the limitations around this? So far I know it's 8x8 tiles of up to 16 colors. Do you think the mode could be modified to use 16x16 tiles? How many unique tiles could I use? Are the tiles in RAM?
The tiles are in ROM. Code tiles mean that the tiles are not output from a tile bitmap (for example like in Mode 3 where a 8x8 tile is generated from 64 bytes encoding each of the pixel values), rather that a special code is generated for each tile to output it. The generator is part of the video mode, so this is not a problem (that is, you can generate a tileset from a normal bitmap). The impacts are the followings:
  • The tileset will occupy a lot of ROM space (about 20Kbytes for 100 tiles if they are very diverse).
  • You can have no RAM background tiles at all (you need to use sprites for anything you can not solve using tiles from the tileset).
The mode can not be modified to 16x16 as both horizontally and vertically the code architecture realizing the tiles is very constrained. A similar mode could be written using 16x16 tiles, but that would be an entirely different mode, and this is something ridiculoulsly complex (it could be possible, but I really wouldn't do it). The maximal tile count depends. The code architecture is capable to generate code for up to 20Kbytes. You may have up to 256 tiles in this if they are simpler. Tiles compress if they have identical rows, so actually in this mode the cout of different tile rows is which matters (The easiest is to think about it like every tile is being defined by 8 pointers pointing in a table of 8 pixel wide tile rows, so any tile row can be reaused any number of times. The "pointers" themselves don't affect ROM usage, so having only 80 tiles or using up the whole 256 set doesn't matter, actually unused tiles will produce tile 0).
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

That's awesome information, thanks. I'll try to create duplicate rows in some of the tiles for the design.With what I'm pixeling it so happens that will be possible.
Post Reply