Mode 72 development
Re: Mode 72 development
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 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.
Re: Mode 72 development
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.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 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.
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).
Re: Mode 72 development
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?
Re: Mode 72 development
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:
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:
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.
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
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
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.
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Mode 72 development
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.
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.
Re: Mode 72 development
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.
Re: Mode 72 development
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.
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.
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.
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.
Re: Mode 72 development
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?
Re: Mode 72 development
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: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 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).
Re: Mode 72 development
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.