It is currently Fri Dec 14, 2018 1:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Aug 27, 2018 9:32 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
DRW wrote:
I think you should try to keep all of the code in the fixed bank and only use the several banks for data. This way, the control of the program is always in the fixed bank. Otherwise you might run into an issue when your code from a variable bank needs data from yet another bank.

This is not a problem with mappers like FME-7 though, where you have 5 bank slots available (only one of which is fixed).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 7:17 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
I think from everyone comments I have a good idea what to test. The state management code should stay in the main bank, code like for title screen, main menu should be in the same bank as their assets, and the rest I will experiment based on space.

Got plenty of ideas to test. Thanks everyone!


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 7:58 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
Also, make sure that code in non-fixed banks really only uses stuff from its own bank and from the fixed bank, but not from another bank.

For example, if you have a pause screen that uses its own color palettes, then unpausing the game needs to set the palettes back to the original level values.

If you saved the original colors into an array in RAM before, then everything is alright.

But if you re-read the level colors from the corresponding ROM location, you better do this after the pause screen functions have ended.
Remember: If your pause screen functions are in the variable bank and your colors are stored in another variable bank, then switching to the color bank while the pause screen functions are running will pull the code away and your game will crash.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 9:39 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
Yes, this is something I will have to be careful about. At first I selected the wrong bank and since it was only the data the impact was a very "interesting" map but with code, that won't be as forgiving :lol:

I will keep that in mind while testing. thanks.


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 5:02 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
Another, non-technical hint:

I created a naming scheme for my constants and functions, so that I always know which banks I need to set.

First, I gave every bank a short name, like "Lvl" for level data and so on.

Every constant that is located in this bank gets a postfix:
const byte Screen1_bLvl[]

This way, I always know that I have to change the bank before using this constant.

The same goes for pointer variables that access those arrays:
const byte *CurrentScreen_bLvl
This variable is not tied to a bank since it's a variable in RAM. But it will point to something in a bank, so it gets the postfix as well.

Functions get the naming scheme as well:
void __fastcall__ LoadCurrentScreen_bLvl(void)
This postfix can mean one of two things:
Either the code of this function is stored in a bank itself.
Or the code accesses data from another bank, but doesn't set the bank itself.
In both cases, I must be sure that the corresponding bank is set before I call the function.

If a function changes banks itself, they get this:
void __fastcall__ SomeFunction_setsB(void)
This way you know that calling this function will change the bank, so if you rely on a bank that you set before calling this function, you need to set it again.


Remember that those names need to be done recursively:
If you put an array in a variable bank, then all functions who call this array need their name changed. And all functions who call those functions need their names to be changed as well and so on. Unless one function sets the corresponsing bank. In this case, this function only needs the "_setsB" postfix:
Code:
Screen1_bLvl
--> referenced by CurrentScreen_bLvl
    --> used in LoadCurrentScreen_bLvl()
        --> called in LoadAllLevelData_bLvl()
            --> called in ProcessGameLogic_setsB() after SwitchBank() was called

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group