Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Frontier Force (another fixed screen shoot-em-up)

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Frontier Force (another fixed screen shoot-em-up)
Post Posted: Wed Feb 14, 2024 10:26 pm
I've started prototyping a new SMS game in Python. I think it will end up saving me a lot of time if I can iron out all the design issues before moving to SMS dev (using the devkit again).

Here's a brief gif of an early feel for the game. I have a lot of the design written out, it's not too complicated but I think it'll be a deeper and longer game than my previous game Blast Arena.

  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 886
  • Location: Spain
Reply with quote
Post Posted: Thu Feb 15, 2024 7:02 am
It looks already very Master System-ish!!

Looking forward to it!
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 670
  • Location: London, UK
Reply with quote
Post Posted: Thu Feb 15, 2024 8:34 am
badcomputer wrote
I've started prototyping a new SMS game in Python. I think it will end up saving me a lot of time if I can iron out all the design issues before moving to SMS dev (using the devkit again).

That's a good trick. I've been idly thinking about the possibility of a code generator to fasttrack converting high level prototypes into assembly code which I might try one day in the future.

Are you using Pygame, or something else?
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Thu Feb 15, 2024 12:53 pm
kusfo wrote
It looks already very Master System-ish!!

Looking forward to it!


Thanks kusfo!

willbritton wrote
That's a good trick. I've been idly thinking about the possibility of a code generator to fasttrack converting high level prototypes into assembly code which I might try one day in the future.

Are you using Pygame, or something else?


I'm using Pyxel which is like Pico-8 for Python. It has a lot of nice features to speed up making 8-16bit era games. Pygame is good too but is more of a general game library.

https://github.com/kitao/pyxel
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 670
  • Location: London, UK
Reply with quote
Post Posted: Thu Feb 15, 2024 1:28 pm
Oh fun! I'll definitely check that out, thanks!
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Sat Feb 17, 2024 4:36 pm
Finalising the look of the game and starting to add weapons and enemies.
alpha-02.png (10.33 KB)
alpha-02.png

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Feb 21, 2024 5:19 pm
More work on this today. Adding enemy and collision behaviours and more graphics stuff. A very work in progress title screen, but the colours and style of the game is beginning to take shape.
alpha-03.png (12.18 KB)
alpha-03.png
titles-alpha-03.png (2.22 KB)
titles-alpha-03.png

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Thu Feb 22, 2024 9:23 pm
More basic functionality and design tweaks today, things coming together now. I'll be able to start testing gameplay soon, which was the whole point of this prototype.
alpha-04-export.gif (430.26 KB)
alpha-04-export.gif

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Sun Mar 03, 2024 1:27 am
More work on this today beginning to add enemy spawning and some new stage stuff. Resisting the feature creep.
alpha-09-volcano.gif (512.54 KB)
alpha-09-volcano.gif

  View user's profile Send private message Visit poster's website
  • Joined: 15 Aug 2019
  • Posts: 260
  • Location: Lancashire UK
Reply with quote
Post Posted: Mon Mar 04, 2024 4:50 pm
This looks class mate, another home run. Well done, looking forward to trying it
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Sat Mar 09, 2024 12:02 pm
Begun transferring the prototype to SMS now (or the emulator), and playing with palette cycling to make the background more interesting.

Will the SMS manage with all this palette stuff when all the sprites are moving around? Stay tuned to find out!

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Sun Mar 10, 2024 11:57 pm
Playing with a different art style for the enemies, I think a softer and brighter style stands out more.

  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 877
Reply with quote
Post Posted: Mon Mar 11, 2024 9:13 am
Looks great.
  View user's profile Send private message
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Tue Mar 12, 2024 10:53 pm
Starting to stress test collisions and such now. I feel like this already performs much better than Blast Arena.

My initial mistake making Blast Arena was thinking sprite drawing would be the bottleneck and so I made a lot of small sized sprites, but the bottleneck by far was collision detection.

This time I intend to use bigger individual enemies in general so that will automatically help by reducing the enemy count but still fill up the screen nicely.

The direction of enemy and player shots are more predictable too so I can remove a lot of checking there.

I also intend to care less about reducing flicker this time, unless it really impacts visibility I don't care for small bits of flicker if it means more action.

Edit: Also as a gift to my future self, posting this thread by Kagesan on Flight of Pigarus development. Very useful info about collision detection, design, scrolling maps etc. https://www.smspower.org/forums/17278-FlightOfPigarusDevelopmentQA

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 13, 2024 4:36 pm
Doing the laser/lightning type weapon.

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Sun Mar 17, 2024 4:41 pm
Title screen is work in progress and main menu fully working today.

I plan to do a bit more with the title screen so splitting them up for now seems like a good idea.

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 20, 2024 10:46 pm
Continuing to make progress. I implemented an score drawing routine in assembly (thanks to sverx thread here) and begun adding the laser weapons.

The laser tile drawing is surprisingly quick so I can probably allow it to be used more often.

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Fri Mar 22, 2024 6:43 pm
Decided to redesign some elements of the game, got rid of some clunky mechanics, and felt it needed more character so added a guy.

As an (unplanned) bonus, getting rid of the side lasers will allow me to optimise enemy bullet to player collisions a lot more.
alpha-08-new-char.png (14.15 KB)
alpha-08-new-char.png

  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Tue Mar 26, 2024 10:06 am
What is the standard way to set up my main loop to ensure music is uninterrupted by slowdown?

I've split my logic and rendering, and split all types of entities, so I can easily skip parts if needed but I'm not sure how to structure this properly to guarantee 100% that music won't slow down.

Do I need to be checking if the previous frame slowed down and then updating music twice in the next? I can't get my head around it.

Any help or advice? Very much appreciated!
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Mar 26, 2024 10:24 am
the *only* safe way to ensure that music won't *ever* slow down is to tie that to an interrupt - for instance if you're not already using the line interrupt, that's the best option.

basically in your handler (that will run once a frame) you have to make sure that you first save and later restore the ROM banking so to do not disrupt other processes (say some VRAM updates from data in ROM) and call the PSGFrame/PSGSFXFrame functions.

example:
void my_handler (void) {
  SMS_saveROMBank();

  SMS_mapROMBank(your_music_bank);
  PSGFrame();   // update music

  SMS_mapROMBank(your_sfx_bank);
  PSGSFXFrame (void);   // update SFX (if active)

  SMS_restoreROMBank();
}


then you need to 'link' the handler, and configure and enable the interrupt - example:
SMS_setLineInterruptHandler(my_handler);
SMS_setLineCounter(140);   // any value over 96 is good because it fires only once every frame
SMS_enableLineInterrupt();
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Tue Mar 26, 2024 11:42 am
sverx wrote
the *only* safe way to ensure that music won't *ever* slow down is to tie that to an interrupt - for instance if you're not already using the line interrupt, that's the best option.

basically in your handler (that will run once a frame) you have to make sure that you first save and later restore the ROM banking so to do not disrupt other processes (say some VRAM updates from data in ROM) and call the PSGFrame/PSGSFXFrame functions.

example:
void my_handler (void) {
  SMS_saveROMBank();

  SMS_mapROMBank(your_music_bank);
  PSGFrame();   // update music

  SMS_mapROMBank(your_sfx_bank);
  PSGSFXFrame (void);   // update SFX (if active)

  SMS_restoreROMBank();
}


then you need to 'link' the handler, and configure and enable the interrupt - example:
SMS_setLineInterruptHandler(my_handler);
SMS_setLineCounter(140);   // any value over 96 is good because it fires only once every frame
SMS_enableLineInterrupt();


Working perfectly, thank you! This was so much simpler than the solutions I read elsewhere, particularly for N*S.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Aug 2023
  • Posts: 33
Reply with quote
Post Posted: Tue Mar 26, 2024 5:36 pm
What if you wanted to use line interrupts for multi-segmented scrolling?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14744
  • Location: London
Reply with quote
Post Posted: Tue Mar 26, 2024 6:57 pm
You can do it in the frame interrupt, like most games do, but then you waste valuable VBlank time. If you put it at the end of the vblank then it might get a little jittery, but probably not noticeable; and if your vblank handler ends up taking more than a frame, you’ll get slowdown again. The classic “wait for vblank” loop has the same issues.
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Tue Mar 26, 2024 7:51 pm
Another somewhat random newbie question.

I was stress testing the game and caused major slowdown (16 enemies + bullets) and managed to read uninitialised memory according to Emulicious, the game panicked and reset itself.

I don't intend to have more than 8 enemies normally or that level of slowdown ever, should I be concerned about managing to crash/reset/halt the game in this way, or just avoid that amount of slowdown?

The answer may seem obvious (avoid it), but I would've expected the game to remain stable albeit incredibly slow until the frame completed?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14744
  • Location: London
Reply with quote
Post Posted: Tue Mar 26, 2024 9:01 pm
Indeed slowdown should not cause that. In assembly I’d guess you’re messing up the stack somehow but in C I suppose that ought not to be possible.
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 12:34 am
So I seem to have found the issue but I'm not sure why it's doing this.

When a metasprite of an enemy is drawn it's putting the sprite index ($50) into the memory address ($C3F7) of the variable num_player_shots, this tracks the number of active shots to update/draw.

The maximum num_player_shots is 2, so obviously the causes all kinds of crazy stuff if its suddenly increased to 80.

This only seems to be happening when the player gets hit by an enemy bullet and theres greater than around 10 enemies (see in-game shot).

The num_player_shots variable was initialised previously to 0.

Any ideas why it might be doing this?

(Sidenote, I'm using metasprite to draw the 3-wide enemy sprite rather than the SMS_addThreeAdjoiningSprites as I was intending to make it bigger later.)
output-2.png (6.33 KB)
output-2.png
numshotserror.PNG (34.41 KB)
numshotserror.PNG

  View user's profile Send private message Visit poster's website
  • Joined: 09 Aug 2021
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 6:25 am
badcomputer wrote
Any ideas why it might be doing this?

the most common reason for such behavior is buffer overrun. i see no checks for the maximum possible sprites count in the metasprite rendering routine on your screenshot, so it continues to render SAT over the random variables in memory which happen to land after those shadow SAT buffers (SpriteTableY[], and SpriteTableXN[]).
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 7:39 am
I suspect toxa is right - if you're using the sprites with the library compiled with NO_SPRITE_CHECKS then there's no 'safety net' to avoid trying to place more than 64 sprites on screen - the code will just overwrite whatever happens to be in RAM after the SAT buffers.

You can use the library compiled with default settings or you have to make sure yourself that there's no way more than 64 sprites will be placed on screen.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 7:42 am
pw wrote
What if you wanted to use line interrupts for multi-segmented scrolling?


you could do that too by checking a counter variable to see if it's the right moment to drive the music - of course that counter needs to be reset in the vertical interrupt handler, but that's a small waste compared to updating the music during vblank
  View user's profile Send private message Visit poster's website
  • Joined: 09 Aug 2021
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 7:56 am
sverx wrote
compiled with NO_SPRITE_CHECKS

why there even such an option? just to have ability to shoot your leg? :) the case when you never need that (because of the guaranteed small amount of sprites on screen, for instance) unlikely require that paranoic cycle saving, and possible checks in the outer code most likely be just slower.
  View user's profile Send private message
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 8:28 am
sverx wrote
I suspect toxa is right - if you're using the sprites with the library compiled with NO_SPRITE_CHECKS then there's no 'safety net' to avoid trying to place more than 64 sprites on screen - the code will just overwrite whatever happens to be in RAM after the SAT buffers.

You can use the library compiled with default settings or you have to make sure yourself that there's no way more than 64 sprites will be placed on screen.


I'm not using anything non-standard, I've never compiled SMSlib myself.

Looking at the version I'm using NO_SPRITE_CHECKS is also not defined, so I'm not sure why it's using that version?

I'll investigate further.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 8:30 am
toxa wrote
sverx wrote
compiled with NO_SPRITE_CHECKS

why there even such an option? just to have ability to shoot your leg? :)


devkitSMS improvement is mostly driven by user desire so - believe it or not - that option is there because somebody wanted to avoid wasting cycles knowing they weren't going to even get close to using 64 sprites
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 8:34 am
Last edited by badcomputer on Wed Mar 27, 2024 8:36 am; edited 1 time in total
I noticed in SMSlib_metasprite.c it seems to be the wrong way around, only if NO_SPRITE_CHECKS is set then it checks if it's using too many sprites, or am I getting confused?

https://github.com/sverx/devkitSMS/blob/master/SMSlib/src/SMSlib_metasprite.c
nosprchecks.png (17.08 KB)
nosprchecks.png

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 8:35 am
badcomputer wrote
I'm not using anything non-standard, I've never compiled SMSlib myself.


Whoopsy. My mistake. Let me fix the code...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 8:37 am
badcomputer wrote
I noticed in SMSlib_metasprite.c it seems to be the wrong way around, only if NO_SPRITE_CHECKS is set then it checks if it's using too many sprites, or am I getting confused?


No, you're right - I just noticed it myself. :facepalm:
It's recompiling and I'm pushing an update in a minute!

edit: done. Sorry!
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 8:40 am
sverx wrote
badcomputer wrote
I noticed in SMSlib_metasprite.c it seems to be the wrong way around, only if NO_SPRITE_CHECKS is set then it checks if it's using too many sprites, or am I getting confused?


No, you're right - I just noticed it myself. :facepalm:
It's recompiling and I'm pushing an update in a minute!


Thanks sverx!

At least the stress testing was worth it and I'm glad I found the reason.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 8:55 am
badcomputer wrote
At least the stress testing was worth it and I'm glad I found the reason.


Thank you for finding a bug! I suspect many more are around...
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 8:58 am
sverx wrote
badcomputer wrote
At least the stress testing was worth it and I'm glad I found the reason.


Thank you for finding a bug! I suspect many more are around...


Don't say that! haha
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 9:53 am
I don't want to get too philosophical but I'm just a man and the only program assured to have no bugs is an empty program ;)
  View user's profile Send private message Visit poster's website
  • Joined: 09 Aug 2021
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 12:03 pm
sverx wrote
believe it or not - that option is there because somebody wanted to avoid wasting cycles knowing they weren't going to even get close to using 64 sprites

mostly, people not know what they really need. they think they saved 20 cycles, but instead wasting 2000 cycles trying to workaround limitations they produced by that previous "optimization". not that i am teaching you how to design the libraries or giving any suggestions though... just my thoughts on the subject.
  View user's profile Send private message
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 3:43 pm
Back to progress, added a new sprite and bg.

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 27, 2024 5:13 pm
toxa wrote
mostly, people not know what they really need. they think they saved 20 cycles, but instead wasting 2000 cycles trying to workaround limitations they produced by that previous "optimization"


Not necessarily they need to check they're not using too many sprites - some games I've seen never even get close to 50 on screen at the same time. But I do not suggest this option in general - as you said, it's possible to shoot yourself in the foot.

(also, for context, an SMS_addSprite call takes 162 CPU cycles, down to just 116 for the NO_SPRITE_CHECKS version)
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Wed Mar 27, 2024 10:29 pm
badcomputer wrote
Back to progress, added a new sprite and bg.


What would be the best way to scroll the sky on this stage in 3 horizontal strips? I already have a line interrupt set up on 140 for the audio update but I can't seem to get scrolling to work properly with further interrupts without seriously messing up the screen.

I guess I'm interrupting screen updates or something but I don't know the best way around this?

I don't need to load any new tiles, just adjust/wrap scroll x in 3 stages continuously. Although I am writing a column of black tiles on the right to even the screen, so I guess I'd need to update that.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Mar 28, 2024 8:05 am
First of all, when you do horizontal scroll you usually turn off the leftmost column of BG on screen so that it doesn't display garbage - you can use
SMS_VDPturnOnFeature(VDPFEATURE_LEFTCOLBLANK);


Also the line interrupt triggers after N lines, N being the value you set using SMS_setLineCounter, so if you set this to 40 for example, your handler will be called after 40 lines, again after 80 lines, then after 120 lines and also after 160 lines. Handling multiple strips of different height is more complex unfortunately, and can be done in different ways: the simpler is breaking down the strips into more strips of the same height, say every 20 instead of 40 if you want the interrupt to also fire at 100th line. The other approach is more complex and it involves updating the line counter value during the interrupt, which will unfortunately result in the value being updated *after* the *next* interrupt invocation... and it's a pain, honestly, so I suggest you the former approach.

edit:
You might also want to lock the HUD in place using
SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL);
which will make the topmost two rows on screen not be affected by the X scroll value.
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Thu Mar 28, 2024 8:53 pm
sverx wrote
First of all, when you do horizontal scroll you usually turn off the leftmost column of BG on screen so that it doesn't display garbage - you can use
SMS_VDPturnOnFeature(VDPFEATURE_LEFTCOLBLANK);


Also the line interrupt triggers after N lines, N being the value you set using SMS_setLineCounter, so if you set this to 40 for example, your handler will be called after 40 lines, again after 80 lines, then after 120 lines and also after 160 lines. Handling multiple strips of different height is more complex unfortunately, and can be done in different ways: the simpler is breaking down the strips into more strips of the same height, say every 20 instead of 40 if you want the interrupt to also fire at 100th line. The other approach is more complex and it involves updating the line counter value during the interrupt, which will unfortunately result in the value being updated *after* the *next* interrupt invocation... and it's a pain, honestly, so I suggest you the former approach.

edit:
You might also want to lock the HUD in place using
SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL);
which will make the topmost two rows on screen not be affected by the X scroll value.


Thanks sverx.

Testing this, is there a reason the interrupt seems to be firing late?

Say if I use SMS_setLineCounter(16) and use my own counter to tell which number interrupt I'm on. I set scroll x in the interrupt it will set it starting from line 18, and the period to the next one is 17 lines but should be 16. What could be causing this or is this expected?

I've attached a short gif to show. It should be scrolling at different speeds at line 16-31 (just below HUD), line 32-103 and line 104-119.

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Mar 29, 2024 12:45 pm
badcomputer wrote
Testing this, is there a reason the interrupt seems to be firing late?


Yes. The issue basically is that there's very very VERY little time to do anything before it's too late to update the scroll register in time for the next row.

Basically the only way to be sure this will work is to have an handler in this form:
void my_handler (void) {
  INLINE_SMS_setBGScrollX (parallax_scroll_X);  // do this immediately!

  // prepare the value for the next parallax_scroll_X here,
  // then do the rest of the work you need to do
}
so that the VDP scroll register gets updated as early as possible.

Of course you have to set the initial value for the global variable parallax_scroll_X in your vblank, for instance doing something like
parallax_scroll_X=my_scroll_table[0];
and using a global variable as an index to your my_scroll_table to pull the next value in your line interrupt handler.

It's not that straightforward, but it works :)

edit: I forgot to mention that to have it fire after line #15 (and after every 16 lines) you have to use
SMS_setLineCounter(15);
because 0 means 'after every line', 1 is after every second line, and so on...
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Fri Mar 29, 2024 4:24 pm
sverx wrote

Yes. The issue basically is that there's very very VERY little time to do anything before it's too late to update the scroll register in time for the next row.


Using 15 on the line counter got it to trigger every 16 lines but I couldnt get it to start on line 16, only 17. I settled for that anyway and adjusted my tile graphics 1 pixel as it was still triggering every 16 like I wanted.

I scrolled the ground too. I haven't decided yet if it causes motion sickness or not!

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Mar 29, 2024 5:31 pm
badcomputer wrote
Using 15 on the line counter got it to trigger every 16 lines but I couldnt get it to start on line 16, only 17.


Uhm, I suspect I know why this is happening.
If you want to experiment with this, you could move everything apart for the INLINE_SMS_setBGScrollX call into a separate function so that your handler remains absolutely minimal like this:
void my_handler (void) {
  INLINE_SMS_setBGScrollX (parallax_scroll_X);  // do this immediately!
  line_handler_process();  // here we process everything we have to do
}


This way SDCC won't have to create any stack frame handling code for the my_handler function and I suppose it'll work.
  View user's profile Send private message Visit poster's website
  • Joined: 19 Oct 2023
  • Posts: 131
Reply with quote
Post Posted: Fri Mar 29, 2024 8:43 pm
sverx wrote
badcomputer wrote
Using 15 on the line counter got it to trigger every 16 lines but I couldnt get it to start on line 16, only 17.


Uhm, I suspect I know why this is happening.
If you want to experiment with this, you could move everything apart for the INLINE_SMS_setBGScrollX call into a separate function so that your handler remains absolutely minimal like this:
void my_handler (void) {
  INLINE_SMS_setBGScrollX (parallax_scroll_X);  // do this immediately!
  line_handler_process();  // here we process everything we have to do
}


This way SDCC won't have to create any stack frame handling code for the my_handler function and I suppose it'll work.


It worked, thanks!
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3827
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Mar 30, 2024 5:29 pm
badcomputer wrote
It worked, thanks!


Good! :D
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!