Mode 72 development

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Hi Jubation, I'm not sure your latest patch caught all the bugs (I have your commit 73f025b8da86abbe52d148776c7d389c54ee9996 merged in):

Code: Select all

_obj_/tileset.o: In function `tilerow_block_32':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1188: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_34':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1201: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_44':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1214: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_55':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1227: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_56':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1240: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_92':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1253: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_0':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1266: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_1':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1279: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_2':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1292: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_3':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1305: relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
_obj_/tileset.o: In function `tilerow_block_8':
..\kernel\videoMode72\examples\city-in-the-sky/tileset.s:1318: additional relocation overflows omitted from the output
make: *** [_bin_/m72demo.elf] Error 1
However I just tried it with my new single row of tiles and it worked. Maybe it was because I recompiled `a` executable now?
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: Tue Mar 20, 2018 2:42 am Jubatian, how does the m72_rowoff variable work in the sample code? The maths for it is relatively complex, but the main thing I don't understand is why it reads the values inside main_vram:

Code: Select all

m72_rowoff[i] = (u16)(&main_vram[((u16)(i) * 32U) + (j >> 3)]) + ((u16)(j & 7U) << 12);
The description of this can be found in videoMode72.s, line 156, it is a pointer to RAM providing the tiles combined with a scroll shift. What you see in the example code is that I get the address of a location (note the "&" before "main_vram", I use indexing instead of pointer arithmetic to calculate it), then add the horizontal scroll shift to it.
rocifier wrote: Tue Mar 20, 2018 2:42 amEDIT: Also another question if you don't mind :) how can I build a mode72 example without the top and bottom text panels? I don't wish to use those in my game at this time. But it looks like there is a whole .s file dedicated to rendering them which I'd rather not include. Too difficult? Just set a null pointer to the text tables?
Currently there is no flag to remove the text mode, but like in the example, you can hide it. When I designed the mode I imagined that people would need the text mode as otherwise due to the background size you could possibly only output text using sprites, and in the previous iteration of the mode, you couldn't even multiplex "unlimited" sprites, you had at most 18. The current Mode 72 however may actually provide okay support for some text using sprites, so I guess the request is totally valid, and it would save you a good chunk of ROM.
rocifier wrote: Tue Mar 20, 2018 6:04 amHi Jubation, I'm not sure your latest patch caught all the bugs (I have your commit 73f025b8da86abbe52d148776c7d389c54ee9996 merged in):
Could you attach the .h file for which this is generated? Possibly another bug in the generator (it is not a simple thing, so it can happen!).
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Jubatian wrote: Tue Mar 20, 2018 6:33 am Could you attach the .h file for which this is generated? Possibly another bug in the generator (it is not a simple thing, so it can happen!).
Don't worry it was just me being dumb and not rebuilding a.exe with the same tileset.h file I tried before.
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Jubatian wrote: Sun Mar 18, 2018 10:51 am Just a note: If you compile the example with your tileset, the sprites may disappear. This is a deficiancy of the example: Sprites sourced from the Flash need to be in the 0x8000 - 0xEFFF range, and your tileset is too small to push them beyond 0x8000, so they become RAM sourced sprites.
Hmm so I've been reading up a lot on the wiki and studying examples. But I'm still a bit confused over this.. I think I need just a little more hand-holding before I dive into my game. Assuming I have a small amount of tiles in mode72, are you able to assist with:

- Some hints of how I might fix the example to work with just a few tiles.. I'm seeing a solid background colour and no sprites, mostly as suspected.
- There is a hole in my understanding of the memory layout... how can having more code tiles push sprites into RAM? how can the memory model be that continuous?

I might just need some links to the right resources since I may have missed something important (for example I didn't read through all of Weber's Rants yet, uncertain if that contains the answers I seek)
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: Tue Mar 20, 2018 11:11 am- There is a hole in my understanding of sprites.. why is the default behavior to source them from flash? Actually now im really in a muddle with terminology; does flash = ROM or flash = SD Card?
Sorry for that, the terminology is typically as follows:
  • RAM: The ATmega644's SRAM (4 KBytes)
  • ROM: The ATmega644's ROM (64 KBytes, 60KBytes available for games)
  • Flash: Also the ATmega644's ROM, this is used because the datasheet often refer it as Flash as it uses Flash technology
  • SD: Data on the SD card
  • SPI RAM: Data on the SPI RAM
I don't think anyone used "Flash" here for the contents of the SD card, anyway, if so, it shouldn't be done as the microcontroller's own ROM is often referred as Flash too. The SPI RAM is neither referred as RAM or SRAM.
rocifier wrote: Tue Mar 20, 2018 11:11 am- Some hints of how I might fix the example to work with just a few tiles.. I'm seeing a solid background colour and no sprites, mostly as suspected.
To get it working for now, do the followings:
  • Add this line to your Makefile (somewhere after the definition of LDFLAGS): "LDFLAGS += -Wl,--section-start=.sprites=0x8000"
  • Replace the section attribute in main.c for the sprites as follows: "static const unsigned char sprdata[] __attribute__ ((section (".sprites")))"
This should get it working for now. Anyway, as I mentioned in the game's topic, I will create you a version of the sprite mode which lacks RAM sprites, making this issue disappear. I think I will also change this in normal modes too to make ROM sprites rather using the lower half of the address space as the usual PROGMEM attribute ensures linking before the code (including the background tileset), to allow for things to keep working on bigger ATmegas and XMegas: program data meant to be accessible with "lpm" has to be in the first 64Kbytes, and the standard linker scripts are designed to ensure this (I wasn't aware of this when I created the mode).
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

I added a new sprite mode fitting your game along with a change to ease locating ROM sprites.

The new mode's description can be read in the mode's source file. It has bullets prioritized over sprites (so bullets show over them), and also has a little more options to spread the HBlank time between sprites and bullets.

You can select sprite modes by enabling them first in the Makefile as needed, the example has this on line 19 of it's Makefile, the M72_SPRITE_MODES definition controls this. To have sprite mode 5 available, OR 0x0020 to this. Selecting only the sprite modes you are actually using saves ROM.

Within the main source, set the appropriate sprite mode by the high nybble of m72_config, like on line 191 of the example's main.c.

Switching between sprite mode 0 and sprite mode 5 requires no changes in code since they are almost identical by function.

Now you will have to just define your sprite data in PROGMEM and it will work fine. It is still limited to half of the ROM, but now the lower half (and PROGMEM is aligned to the beginning, so it is fine), I forgot that the X mirror flag is on bit 7 of the address.

Still I didn't add an option to remove the text mode, I will do that next time (I guess you don't need that 5K of ROM right now, do you? :) )
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Jubatian wrote: Tue Mar 20, 2018 8:26 pm I added a new sprite mode fitting your game along with a change to ease locating ROM sprites.

The new mode's description can be read in the mode's source file. It has bullets prioritized over sprites (so bullets show over them), and also has a little more options to spread the HBlank time between sprites and bullets.

You can select sprite modes by enabling them first in the Makefile as needed, the example has this on line 19 of it's Makefile, the M72_SPRITE_MODES definition controls this. To have sprite mode 5 available, OR 0x0020 to this. Selecting only the sprite modes you are actually using saves ROM.

Within the main source, set the appropriate sprite mode by the high nybble of m72_config, like on line 191 of the example's main.c.

Switching between sprite mode 0 and sprite mode 5 requires no changes in code since they are almost identical by function.

Now you will have to just define your sprite data in PROGMEM and it will work fine. It is still limited to half of the ROM, but now the lower half (and PROGMEM is aligned to the beginning, so it is fine), I forgot that the X mirror flag is on bit 7 of the address.

Still I didn't add an option to remove the text mode, I will do that next time (I guess you don't need that 5K of ROM right now, do you? :) )
Wow thanks man!! I can't wait to try this tonight!
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Awesome the example sprites are all back, but this time much easier to set up :D

Now I just need to work on getting my background tiles to show up. Currently I'm seeing palette index 0 filling the whole background, though I didn't use that colour in any of the tiles.

EDIT: might be a generator problem.. attached is my tileset.s file which looks quite broken (too simple)
Attachments
tileset.s.txt
generated .s
(51.19 KiB) Downloaded 655 times
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

Ok I found what was happening.. I was building tilegen.c from a different directory so the output was going to the wrong directory. Rookie mistake. Shit actually works now.
rocifier
Posts: 71
Joined: Thu Jan 22, 2015 6:35 am

Re: Mode 72 development

Post by rocifier »

So I kind of overlooked something rather important.. my background needs to be changed as the user plays the game. So I kind of need it in RAM not ROM, lol..

EDIT: Ok I just went back and looked at the example and I didn't overlook it, you're just initializing the vram once from an array in flash. I should probably focus on this after work :D :D
Post Reply