Forums

cireza wrote

Edit : I tried but it seems it is still not going at the expected place :(
Stays at 3F00

Just looking at the code for makesms and I think I can see how this might be happening.

Out of interest, do you still see a log line of "Info: SEGA header found, checksum updated" when you run it?

willbritton wrote

Out of interest, do you still see a log line of "Info: SEGA header found, checksum updated" when you run it?

Yes, I do get this log.

So I'm wondering if the problem is with the interaction between the header macro(s) and how makesms treats banked segments.

You might just try either modifying SMSlib.h directly or else writing your own copy of the macro to test this out, but basically what I'm thinking is that instead of

#define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \
const __at (0x7ff0) unsigned char __SMS__SEGA_signature[16]= //...snip

it might work better with

#define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \
const __at (0x17ff0) unsigned char __SMS__SEGA_signature[16]= //...snip

Note the modified offset to specify bank 1.

If that helps, then I think we might be onto something, but not sure what the most appropriate "proper" fix would be in that case.

So it seems I have things working now, I made this change :

#define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \
const __at (0x17ff0) unsigned char __SMS__SEGA_signature[16]={'T','M','R',' ','S','E','G','A', \
0xFF,0xFF,0xFF,0xFF, \
SMS_BYTE_TO_BCD((productCode)%100),SMS_BYTE_TO_BCD(((productCode)/100)%100), \
(((productCode)/10000)<<4)|((revision)&0x0f),SMS_EMBED_SEGA_ROM_HEADER_REGION_CODE}

#define SMS_EMBED_SDSC_HEADER(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr) \
const __at (0x17fe0-sizeof(author)) char __SMS__SDSC_author[]=author; \
const __at (0x17fe0-sizeof(author)-sizeof(name)) char __SMS__SDSC_name[]=name; \
const __at (0x17fe0-sizeof(author)-sizeof(name)-sizeof(descr)) char __SMS__SDSC_descr[]=descr; \
const __at (0x17fe0) char __SMS__SDSC_signature[16]={'S','D','S','C', \
SMS_BYTE_TO_BCD(verMaj),SMS_BYTE_TO_BCD(verMin), \
SMS_BYTE_TO_BCD(dateDay),SMS_BYTE_TO_BCD(dateMonth), \
SMS_BYTE_TO_BCD((dateYear)%100),SMS_BYTE_TO_BCD((dateYear)/100), \
(0x7fe0-sizeof(author))%256, \
(0x7fe0-sizeof(author))>>8, \
(0x7fe0-sizeof(author)-sizeof(name))%256, \
(0x7fe0-sizeof(author)-sizeof(name))>>8, \
(0x7fe0-sizeof(author)-sizeof(name)-sizeof(descr))%256, \
(0x7fe0-sizeof(author)-sizeof(name)-sizeof(descr))>>8}

I added the 1 in front of the address at several places, but not the final ones as they lead to a char overflow. Not too sure if this is correct.

Ah yeah okay that makes sense that there are a few more places than the one I highlighted, but principle's the same.

You're right that it won't work with the final ones, since they are pointers within the SDSC header which are relative to the real memory space, so in fact they do need to refer to a base of 0x7fe0 rather than 0x17fe0.

Great that you've got it working! But as I said, this is just a hack really - at least it proves the problem, which is that the header code is being emitted to real addresses, not virtual ones and so when the final ROM is assembled they get lost.

I suppose one potential fix is to change makesms to detect the header code and force it to be written to bank 1. There is already code in makesms which detects the SMS header, in order to calculate the checksum, so maybe it could go there.

EDIT: just another thought, perhaps it's simpler than this - the problem in makesms is that it masks all source addresses within a segment with 0x3fff which perhaps is just not the right thing to do. I'll have a think and if I feel like I've got a solid fix in mind I'll maybe make a PR.

Without having time to look much more into it at the moment, I wonder whether ihx2sms suffers from the same problem and at a glance I would guess that it does; but since the usual way to do non-code banking is in slot 2 the issue rarely comes up.

Let's maybe see what sverx thinks when he's back in the neighbourhood!

when using banked code, you likely want your ROM signature (and SDSC signature) at the end of bank0, so you should use:

SMS_EMBED_SEGA_ROM_HEADER_16KB(productCode,revision)

and

SMS_EMBED_SDSC_HEADER_16KB(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr)

or if you want the SDSC date to be 'automatic' (set by makesms)

SMS_EMBED_SDSC_HEADER_AUTO_DATE_16KB(verMaj,verMin,author,name,descr)

pw wrote

When looking at the SMS_add****AdjoiningSprites_f functions, I've noticed that at the beginning it does a check to see if there are enough sprites free to draw the row and exits early if it doesn't. Yet later on in the function, it checks the limit for every sprite and returns if it does. Did I read that right?

Well, no. At the beginning, they check if there are enough sprites available to draw the entire strip (say 3 sprites) and won't draw anything if the available number of sprites isn't sufficient. But then, depending on the X position of the leftmost sprite, there could be sprites that will be completely clipped out of the right screen border, so the function in the end updates how many sprites were actually used.

I hope this explanation makes sense! :)

sverx wrote

when using banked code, you likely want your ROM signature (and SDSC signature) at the end of bank0, so you should use:

SMS_EMBED_SEGA_ROM_HEADER_16KB(productCode,revision)

and

SMS_EMBED_SDSC_HEADER_16KB(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr)

or if you want the SDSC date to be 'automatic' (set by makesms)

SMS_EMBED_SDSC_HEADER_AUTO_DATE_16KB(verMaj,verMin,author,name,descr)

I think that cireza was saying having the header in bank 0 was preventing it from being detected as GG on the Everdrive though.

In fact, the header @0x7FF0 is completely empty

Look at Cireza's screenshot :
https://www.smspower.org/forums/files/compiled_with_makesms_180.png

willbritton wrote

I think that cireza was saying having the header in bank 0 was preventing it from being detected as GG on the Everdrive though.

oh, wait, does the EverDrive-GG really checks any ROM header? I don't think so - and I guess it uses the file extension to decide if the ROM should run in GG mode or in SMS mode.

Please correct me if I'm wrong, I never used/had an EverDrive-GG myself...

edit: I just remembered that there is an (unresolved I guess?) issue with the EverDrive-GG software that appears when the ROM file name fits into the 8.3 format (such as ROM.gg) - so please make sure to give a sensible name such as game_test_ROM.gg or similar.

To the best of my knowledge, no EverDrive care about no header.

sverx wrote

Please correct me if I'm wrong, I never used/had an EverDrive-GG myself...

You can still test it by emulating the Everdrive in Emulicious. It does check the filename but it also checks a bit of the rom. Afaik the filename is used to determine GG vs. SMS and the rom contents are only checked to determine SEGA mapper vs. Codemasters mapper.

Well here's what we know from cireza's original issue as reported:

cireza wrote

For some reason, I am not getting the expected information at address 0x7FF0 in my rom.
...
The result is that my Game Gear/Everdrive treats the rom as a SMS game instead of a GG game (the rom is named rom.gg).

and

cireza wrote

...my headers end up at the end of bank0.

Also that when he persuaded the header to appear at 0x7FF0 again the implication was that the problem was solved.

But I agree, it seems strange that it's not purely down to file extension. Cireza didn't say what Everdrive "treat[ing] the rom as a SMS game" actually means in practice - does that mean it ran on the GG in SMS compatibility mode?

@Calindro - do you know how the algorithm Everdrive uses to decide the mapper actually works? Could the wrong choice of mapper be causing the issue somehow?

My rom was simply named rom.gg but it appeared in SMS mode indeed. The fact that the header was not present at 7FF0 is what I supposed caused the issue, but please keep in mind that you are all much more knowledgeable about these consoles than I am. I simply made the assumption because it was the only difference that I spotted.

I will try to use the 16KB header as suggested by sverx, thank you.

cireza wrote

I will try to use the 16KB header as suggested by sverx, thank you.

I would see if you can make it work correctly without any header first.

Also, are you using the 'legacy' EverDrive-GG or the 'newer' EverDrive GG X7? And are you using the latest available 'OS' version?

sverx wrote

I would see if you can make it work correctly without any header first.

Also, are you using the 'legacy' EverDrive-GG or the 'newer' EverDrive GG X7? And are you using the latest available 'OS' version?

I am using the first Everdrive GG and not the latest OS as it introduced issues with saving, if I remember correctly. Support has been pretty poor for the OS of the original Everdrive GG.

In devkitSMS/SMSlib/src/how to build this.txt:

the build instructions lack the reference to SMS_addthreesprites file

Regards

eruiz00 wrote

the build instructions lack the reference to SMS_addthreesprites file

fixed! thanks :)

I just pushed an update adding SMS_debugPrintf

void SMS_debugPrintf(const unsigned char *format, ...)

which (so far) works only with Emulicious, provided it's updated (at least to yesterday's release)

use it as the regular printf() so for instance:

SMS_debugPrintf("Player 1 HP = %d, Player 2 HP = %d\n", player1.HP, player2.HP);

the output will appear in Emulicious' Console window.

sverx wrote

I just pushed an update adding SMS_debugPrintf

void SMS_debugPrintf(const unsigned char *format, ...)
which (so far) works only with Emulicious, provided it's updated (at least to yesterday's release)

use it as the regular printf() so for instance:

SMS_debugPrintf("Player 1 HP = %d, Player 2 HP = %d\n", player1.HP, player2.HP);

the output will appear in Emulicious' Console window.

Thank you for this update. If I get into trouble debugging my new game I will use it.

So I decided I could add some (basic) metasprite support after all.

What's a metasprite in devkitSMS? It is a list of sprites that have horizontal and vertical offsets from an origin point, so that placing a metasprite origin at some place, all the hardware sprites will be placed accordingly.

So to use metasprites you need definitions. A definition is a list of how many sprites you need, with an horizontal offset (signed byte), vertical offset (signed byte) and tile number for each sprite. The list ends with a METASPRITE_END marker. Example:

unsigned char const metasprite0[]={
// x_off, y_off, tile#
0, 0, SPRITES_START_TILE,
0, 16, SPRITES_START_TILE+1,
15, 5, SPRITES_START_TILE+2,
9, -13, SPRITES_START_TILE+6,
-9, -13, SPRITES_START_TILE+1,
-15, 5, SPRITES_START_TILE+1,
METASPRITE_END};

(SDCC may warn you about the mixed signedness and/or for data truncation, just ignore that...)

Then you call SMS_addMetaSprite(pos_x, pos_y, metasprite) and you get the sprites added, like regular sprites that you later will copy to SAT with SMS_copySpritestoSAT().

The function handles clipping - it won't draw sprites falling completely outside of the screen, but has a different behavior regarding how it handles the pos_x and pos_y origin point:

pos_x can only be 0-255, so you can't place the metasprite origin point horizontally outside of the screen.
pos_y can be any value -128 to 255, so the origin point can be placed vertically outside the screen: for instance a player can jump high over the top border or fall down in a pit and disappear below the bottom border. Note that there is vertical wrap on 8 bits anyway so you want to limit your range -k to 255-k.

SMS_addMetaSprite(hero_x, hero_y, metasprite0);

Then of course you can create arrays of metasprites definitions

unsigned char const *metasprites[]={metasprite0, metasprite1, metasprite2, metasprite3, metasprite4, metasprite5};

and use them as frames for your animations.

You can even skip some of the sprites in the list, provided you put them in the beginning - all you have to do is to skip 3 bytes for each sprite for example:

SMS_addMetaSprite(hero_x, hero_y, metasprite0+3);

Here's a little demo. I hope you like it :)

MetaSpriteDemo.sms.zip (1.77 KB)

devkitSMS MetaSpriteDemo

Interesting, I'll give this a go. Thanks for the update!

note that SMS_addTwoAdjoiningSprites and SMS_addThreeAdjoiningSprites in fact are sort of metasprites functions too, just better suited for a different job

which means sometimes you might find one better suited than the other, so SMS_addMetaSprite is basically opening in a different direction where you need sparse/unaligned sprites

Author	Message
willbritton Joined: 06 Mar 2022 Posts: 533 Location: London, UK	Posted: Sun Sep 17, 2023 2:41 pm
	cireza wrote Edit : I tried but it seems it is still not going at the expected place :( Stays at 3F00 Just looking at the code for makesms and I think I can see how this might be happening. Out of interest, do you still see a log line of "Info: SEGA header found, checksum updated" when you run it?

cireza Joined: 27 Feb 2023 Posts: 108 Location: France	Posted: Sun Sep 17, 2023 2:56 pm
cireza Joined: 27 Feb 2023 Posts: 108 Location: France	willbritton wrote Out of interest, do you still see a log line of "Info: SEGA header found, checksum updated" when you run it? Yes, I do get this log.

willbritton Joined: 06 Mar 2022 Posts: 533 Location: London, UK	Posted: Sun Sep 17, 2023 3:19 pm
	So I'm wondering if the problem is with the interaction between the header macro(s) and how makesms treats banked segments. You might just try either modifying SMSlib.h directly or else writing your own copy of the macro to test this out, but basically what I'm thinking is that instead of #define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \ const __at (0x7ff0) unsigned char __SMS__SEGA_signature[16]= //...snip it might work better with #define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \ const __at (0x17ff0) unsigned char __SMS__SEGA_signature[16]= //...snip Note the modified offset to specify bank 1. If that helps, then I think we might be onto something, but not sure what the most appropriate "proper" fix would be in that case.

cireza Joined: 27 Feb 2023 Posts: 108 Location: France	Posted: Mon Sep 18, 2023 5:57 pm
cireza Joined: 27 Feb 2023 Posts: 108 Location: France	So it seems I have things working now, I made this change : #define SMS_EMBED_SEGA_ROM_HEADER(productCode,revision) \ const __at (0x17ff0) unsigned char __SMS__SEGA_signature[16]={'T','M','R',' ','S','E','G','A', \ 0xFF,0xFF,0xFF,0xFF, \ SMS_BYTE_TO_BCD((productCode)%100),SMS_BYTE_TO_BCD(((productCode)/100)%100), \ (((productCode)/10000)<<4)\|((revision)&0x0f),SMS_EMBED_SEGA_ROM_HEADER_REGION_CODE} #define SMS_EMBED_SDSC_HEADER(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr) \ const __at (0x17fe0-sizeof(author)) char __SMS__SDSC_author[]=author; \ const __at (0x17fe0-sizeof(author)-sizeof(name)) char __SMS__SDSC_name[]=name; \ const __at (0x17fe0-sizeof(author)-sizeof(name)-sizeof(descr)) char __SMS__SDSC_descr[]=descr; \ const __at (0x17fe0) char __SMS__SDSC_signature[16]={'S','D','S','C', \ SMS_BYTE_TO_BCD(verMaj),SMS_BYTE_TO_BCD(verMin), \ SMS_BYTE_TO_BCD(dateDay),SMS_BYTE_TO_BCD(dateMonth), \ SMS_BYTE_TO_BCD((dateYear)%100),SMS_BYTE_TO_BCD((dateYear)/100), \ (0x7fe0-sizeof(author))%256, \ (0x7fe0-sizeof(author))>>8, \ (0x7fe0-sizeof(author)-sizeof(name))%256, \ (0x7fe0-sizeof(author)-sizeof(name))>>8, \ (0x7fe0-sizeof(author)-sizeof(name)-sizeof(descr))%256, \ (0x7fe0-sizeof(author)-sizeof(name)-sizeof(descr))>>8} I added the 1 in front of the address at several places, but not the final ones as they lead to a char overflow. Not too sure if this is correct.

willbritton Joined: 06 Mar 2022 Posts: 533 Location: London, UK	Posted: Tue Sep 19, 2023 8:11 am
	Ah yeah okay that makes sense that there are a few more places than the one I highlighted, but principle's the same. You're right that it won't work with the final ones, since they are pointers within the SDSC header which are relative to the real memory space, so in fact they do need to refer to a base of 0x7fe0 rather than 0x17fe0. Great that you've got it working! But as I said, this is just a hack really - at least it proves the problem, which is that the header code is being emitted to real addresses, not virtual ones and so when the final ROM is assembled they get lost. I suppose one potential fix is to change makesms to detect the header code and force it to be written to bank 1. There is already code in makesms which detects the SMS header, in order to calculate the checksum, so maybe it could go there. EDIT: just another thought, perhaps it's simpler than this - the problem in makesms is that it masks all source addresses within a segment with 0x3fff which perhaps is just not the right thing to do. I'll have a think and if I feel like I've got a solid fix in mind I'll maybe make a PR. Without having time to look much more into it at the moment, I wonder whether ihx2sms suffers from the same problem and at a glance I would guess that it does; but since the usual way to do non-code banking is in slot 2 the issue rarely comes up. Let's maybe see what sverx thinks when he's back in the neighbourhood!

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Thu Sep 21, 2023 10:06 am Last edited by sverx on Thu Sep 21, 2023 10:13 am; edited 1 time in total
	when using banked code, you likely want your ROM signature (and SDSC signature) at the end of bank0, so you should use: SMS_EMBED_SEGA_ROM_HEADER_16KB(productCode,revision) and SMS_EMBED_SDSC_HEADER_16KB(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr) or if you want the SDSC date to be 'automatic' (set by makesms) SMS_EMBED_SDSC_HEADER_AUTO_DATE_16KB(verMaj,verMin,author,name,descr)

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Thu Sep 21, 2023 10:11 am
	pw wrote When looking at the SMS_add****AdjoiningSprites_f functions, I've noticed that at the beginning it does a check to see if there are enough sprites free to draw the row and exits early if it doesn't. Yet later on in the function, it checks the limit for every sprite and returns if it does. Did I read that right? Well, no. At the beginning, they check if there are enough sprites available to draw the entire strip (say 3 sprites) and won't draw anything if the available number of sprites isn't sufficient. But then, depending on the X position of the leftmost sprite, there could be sprites that will be completely clipped out of the right screen border, so the function in the end updates how many sprites were actually used. I hope this explanation makes sense! :)

willbritton Joined: 06 Mar 2022 Posts: 533 Location: London, UK	Posted: Thu Sep 21, 2023 3:48 pm
	sverx wrote when using banked code, you likely want your ROM signature (and SDSC signature) at the end of bank0, so you should use: SMS_EMBED_SEGA_ROM_HEADER_16KB(productCode,revision) and SMS_EMBED_SDSC_HEADER_16KB(verMaj,verMin,dateYear,dateMonth,dateDay,author,name,descr) or if you want the SDSC date to be 'automatic' (set by makesms) SMS_EMBED_SDSC_HEADER_AUTO_DATE_16KB(verMaj,verMin,author,name,descr) I think that cireza was saying having the header in bank 0 was preventing it from being detected as GG on the Everdrive though.

ichigobankai Joined: 04 Jul 2010 Posts: 531 Location: Angers, France	Posted: Thu Sep 21, 2023 3:58 pm
	In fact, the header @0x7FF0 is completely empty Look at Cireza's screenshot : https://www.smspower.org/forums/files/compiled_with_makesms_180.png

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Fri Sep 22, 2023 7:52 am
	willbritton wrote I think that cireza was saying having the header in bank 0 was preventing it from being detected as GG on the Everdrive though. oh, wait, does the EverDrive-GG really checks any ROM header? I don't think so - and I guess it uses the file extension to decide if the ROM should run in GG mode or in SMS mode. Please correct me if I'm wrong, I never used/had an EverDrive-GG myself... edit: I just remembered that there is an (unresolved I guess?) issue with the EverDrive-GG software that appears when the ROM file name fits into the 8.3 format (such as ROM.gg) - so please make sure to give a sensible name such as game_test_ROM.gg or similar. To the best of my knowledge, no EverDrive care about no header.

Calindro Joined: 14 Apr 2013 Posts: 619	Posted: Fri Sep 22, 2023 1:11 pm
Calindro Joined: 14 Apr 2013 Posts: 619	sverx wrote Please correct me if I'm wrong, I never used/had an EverDrive-GG myself... You can still test it by emulating the Everdrive in Emulicious. It does check the filename but it also checks a bit of the rom. Afaik the filename is used to determine GG vs. SMS and the rom contents are only checked to determine SEGA mapper vs. Codemasters mapper.

willbritton Joined: 06 Mar 2022 Posts: 533 Location: London, UK	Posted: Fri Sep 22, 2023 3:22 pm
	Well here's what we know from cireza's original issue as reported: cireza wrote For some reason, I am not getting the expected information at address 0x7FF0 in my rom. ... The result is that my Game Gear/Everdrive treats the rom as a SMS game instead of a GG game (the rom is named rom.gg). and cireza wrote ...my headers end up at the end of bank0. Also that when he persuaded the header to appear at 0x7FF0 again the implication was that the problem was solved. But I agree, it seems strange that it's not purely down to file extension. Cireza didn't say what Everdrive "treat[ing] the rom as a SMS game" actually means in practice - does that mean it ran on the GG in SMS compatibility mode? @Calindro - do you know how the algorithm Everdrive uses to decide the mapper actually works? Could the wrong choice of mapper be causing the issue somehow?

cireza Joined: 27 Feb 2023 Posts: 108 Location: France	Posted: Fri Sep 22, 2023 4:18 pm
cireza Joined: 27 Feb 2023 Posts: 108 Location: France	My rom was simply named rom.gg but it appeared in SMS mode indeed. The fact that the header was not present at 7FF0 is what I supposed caused the issue, but please keep in mind that you are all much more knowledgeable about these consoles than I am. I simply made the assumption because it was the only difference that I spotted. I will try to use the 16KB header as suggested by sverx, thank you.

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Mon Sep 25, 2023 9:06 am
	cireza wrote I will try to use the 16KB header as suggested by sverx, thank you. I would see if you can make it work correctly without any header first. Also, are you using the 'legacy' EverDrive-GG or the 'newer' EverDrive GG X7? And are you using the latest available 'OS' version?

cireza Joined: 27 Feb 2023 Posts: 108 Location: France	Posted: Mon Sep 25, 2023 4:22 pm
cireza Joined: 27 Feb 2023 Posts: 108 Location: France	sverx wrote I would see if you can make it work correctly without any header first. Also, are you using the 'legacy' EverDrive-GG or the 'newer' EverDrive GG X7? And are you using the latest available 'OS' version? I am using the first Everdrive GG and not the latest OS as it introduced issues with saving, if I remember correctly. Support has been pretty poor for the OS of the original Everdrive GG.

eruiz00 Joined: 28 Jan 2017 Posts: 507 Location: Málaga, Spain	Little "bug" in smsdevkit Posted: Mon Oct 30, 2023 9:14 pm
	In devkitSMS/SMSlib/src/how to build this.txt: the build instructions lack the reference to SMS_addthreesprites file Regards

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Tue Oct 31, 2023 7:33 am
	eruiz00 wrote the build instructions lack the reference to SMS_addthreesprites file fixed! thanks :)

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Wed Nov 01, 2023 9:20 am
	I just pushed an update adding SMS_debugPrintf void SMS_debugPrintf(const unsigned char format, ...) which (so far) works only with Emulicious, provided it's updated (at least to yesterday's release) use it as the regular printf()* so for instance: SMS_debugPrintf("Player 1 HP = %d, Player 2 HP = %d\n", player1.HP, player2.HP); the output will appear in Emulicious' Console window.

cireza Joined: 27 Feb 2023 Posts: 108 Location: France	Posted: Sat Nov 04, 2023 7:26 pm
cireza Joined: 27 Feb 2023 Posts: 108 Location: France	sverx wrote I just pushed an update adding SMS_debugPrintf void SMS_debugPrintf(const unsigned char format, ...) which (so far) works only with Emulicious, provided it's updated (at least to yesterday's release) use it as the regular printf()* so for instance: SMS_debugPrintf("Player 1 HP = %d, Player 2 HP = %d\n", player1.HP, player2.HP); the output will appear in Emulicious' Console window. Thank you for this update. If I get into trouble debugging my new game I will use it.

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	devkitSMS MetaSprites Posted: Yesterday at 4:56 pm
	So I decided I could add some (basic) metasprite support after all. What's a metasprite in devkitSMS? It is a list of sprites that have horizontal and vertical offsets from an origin point, so that placing a metasprite origin at some place, all the hardware sprites will be placed accordingly. So to use metasprites you need definitions. A definition is a list of how many sprites you need, with an horizontal offset (signed byte), vertical offset (signed byte) and tile number for each sprite. The list ends with a METASPRITE_END marker. Example: unsigned char const metasprite0[]={ // x_off, y_off, tile# 0, 0, SPRITES_START_TILE, 0, 16, SPRITES_START_TILE+1, 15, 5, SPRITES_START_TILE+2, 9, -13, SPRITES_START_TILE+6, -9, -13, SPRITES_START_TILE+1, -15, 5, SPRITES_START_TILE+1, METASPRITE_END}; (SDCC may warn you about the mixed signedness and/or for data truncation, just ignore that...) Then you call SMS_addMetaSprite(pos_x, pos_y, metasprite) and you get the sprites added, like regular sprites that you later will copy to SAT with SMS_copySpritestoSAT(). The function handles clipping - it won't draw sprites falling completely outside of the screen, but has a different behavior regarding how it handles the pos_x and pos_y origin point: pos_x can only be 0-255, so you can't place the metasprite origin point horizontally outside of the screen. pos_y can be any value -128 to 255, so the origin point can be placed vertically outside the screen: for instance a player can jump high over the top border or fall down in a pit and disappear below the bottom border. Note that there is vertical wrap on 8 bits anyway so you want to limit your range -k to 255-k. SMS_addMetaSprite(hero_x, hero_y, metasprite0); Then of course you can create arrays of metasprites definitions unsigned char const *metasprites[]={metasprite0, metasprite1, metasprite2, metasprite3, metasprite4, metasprite5}; and use them as frames for your animations. You can even skip some of the sprites in the list, provided you put them in the beginning - all you have to do is to skip 3 bytes for each sprite for example: SMS_addMetaSprite(hero_x, hero_y, metasprite0+3); Here's a little demo. I hope you like it :) MetaSpriteDemo.sms.zip (1.77 KB) devkitSMS MetaSpriteDemo

badcomputer Joined: 19 Oct 2023 Posts: 74	Posted: Yesterday at 9:30 pm
badcomputer Joined: 19 Oct 2023 Posts: 74	Interesting, I'll give this a go. Thanks for the update!

sverx Joined: 05 Sep 2013 Posts: 3589 Location: Stockholm, Sweden	Posted: Today at 10:44 am
	note that SMS_addTwoAdjoiningSprites and SMS_addThreeAdjoiningSprites in fact are sort of metasprites functions too, just better suited for a different job which means sometimes you might find one better suited than the other, so SMS_addMetaSprite is basically opening in a different direction where you need sparse/unaligned sprites

Forums

View topic - devkitSMS - develop your homebrew in C