- 10
- Posts
- 12
- Years
- Age 19
- Seen Jun 6, 2023
editeddddd
Last edited:
Development: Secret Bases
- Thread starter Emcitement
- Start date
Jambo51
Glory To Arstotzka
- 736
- Posts
- 14
- Years
- Seen Jan 28, 2018
Unfortunately, the answer is a no. The limit of 16 is imposed by the lack of available RAM for the ROM to store sprite locations in. On this thought, the limit should actually be 15, as opposed to 16, because the player counts as a sprite too.
The only way to safely get around it is to use multiple maps (cleverly used connections or such) or to repoint the sprite storage location into a new save block area, then raise the limit.
This is impractical in many ways though, and there are better/more important things we can repoint into the new save block, like trainerflags, seen/caught flags, variables etc.
The only way to safely get around it is to use multiple maps (cleverly used connections or such) or to repoint the sprite storage location into a new save block area, then raise the limit.
This is impractical in many ways though, and there are better/more important things we can repoint into the new save block, like trainerflags, seen/caught flags, variables etc.
Full Metal
C(++) Developer.
- 810
- Posts
- 16
- Years
- Age 28
- In my mind.
- Seen Aug 19, 2018
He doesn't suggest.
Record Mixing fills in those slots available in the memory.
in C++ terms:
class Base{
private:
sprites sprite[16];//Predefined array size. Therefor, the Base does not support dynamic memory. So when allocating memory for a base, the game only allocates enough memory to allow for information on 16 sprites.
};
std::vector<Base> Bases;
[ read what's bold and red. it's important. ]
The method you're speaking of is:
He doesn't suggest this because:
I'd say he answered your questions fairly well already. :\
Record Mixing fills in those slots available in the memory.
in C++ terms:
class Base{
private:
sprites sprite[16];//Predefined array size. Therefor, the Base does not support dynamic memory. So when allocating memory for a base, the game only allocates enough memory to allow for information on 16 sprites.
};
std::vector<Base> Bases;
[ read what's bold and red. it's important. ]
The method you're speaking of is:
He doesn't suggest this because:
I'd say he answered your questions fairly well already. :\
Deokishisu
Mr. Magius
- 990
- Posts
- 18
- Years
Because the sprites are player placed, there's a technical limit on how many "dynamic" sprite locations can be saved. Even if you were to expand it for your rom, there's no telling what mixing records with an unhacked game would do in terms of placing the extra decorations in your base that appears in their game.
Full Metal
C(++) Developer.
- 810
- Posts
- 16
- Years
- Age 28
- In my mind.
- Seen Aug 19, 2018
^this^ is a very good point.
Deokishisu
Mr. Magius
- 990
- Posts
- 18
- Years
Well, there is an option I brainstormed last night. You could keep the limit of 16 "normally added" secret base items. Then maybe manually script up a way to place more, but those would only be on your game, that data wouldn't be transferred when mixing records.
So you'd have to get a script that gives the option to place more OWs dynamically, and then save them through use of flags or variables or something.
Though I don't know if 16 is a "display at once on screen" limit or like a "can't save any more cause there's no more space in memory" limit.
OR: You could add more sprites AS secret base items, but put two decorations in one sprite. So for one OW, you could put two decorations in it. You'd just have to make sure the palettes are similar. So two blue Pokemon could be on one sprite. That way, you could give the illusion of having more base items, when really you still have the 16 limit. That also would work around the 16 display limit, if in fact I was right in assuming that was what Jambo implied.
So you'd have to get a script that gives the option to place more OWs dynamically, and then save them through use of flags or variables or something.
Though I don't know if 16 is a "display at once on screen" limit or like a "can't save any more cause there's no more space in memory" limit.
OR: You could add more sprites AS secret base items, but put two decorations in one sprite. So for one OW, you could put two decorations in it. You'd just have to make sure the palettes are similar. So two blue Pokemon could be on one sprite. That way, you could give the illusion of having more base items, when really you still have the 16 limit. That also would work around the 16 display limit, if in fact I was right in assuming that was what Jambo implied.
- 275
- Posts
- 13
- Years
- Seen Oct 9, 2019
Does it use a different movement permission?
- 275
- Posts
- 13
- Years
- Seen Oct 9, 2019
I wonder if it's hardcoded into the (for lack of a better phrase) Secret Base engine, then...
P.S. the 16-sprite limit may be both functional and graphical. I don't know if this is true for RSE (it probably is), but in FR/LG there are a max of 16 background palettes (all used for the map and for dialog box borders) and 16 sprite palettes at any given time. Of those sprite palettes, one is used for the hero and another for their reflection in water; four are used for normal OWs, and four more for their reflections; two or three seem reserved for map effects (grass, beach footprints, etc.); and two are always unused.
Can you confirm this? Now it make me kinda scared to do it.