Lucretia - Demon Princess (鬼姫の呪い in Japan) NOW IN BETA TESTING

[touko]

Some collision problems rover  

[nodtveidt]

Nah, not really. Minor thing I've not bothered to go in and correct just yet because I have to rewrite the shot code anyway. As I work on this, I keep thinking of things to add, and as long as they don't break the existing design, they get added. I have an evolving design document for this project, which is how I work best anyway. What has to change in the shot code is patterns... it's currently designed to have each character shoot the same pattern. That got kind of boring pretty fast so I decided to give it some variety. The current code allows the shot patterns to be determined from inside the player input processor function, but it's going to become complicated so I'm moving individual player shot generation code to its own function.

I'm still deciding what to do about bomb-type attacks... got some ideas but haven't implemented anything just yet.

[touko]

LOL yes i know, i had the same problem with my caravan (in revival chase), because my collision routine was byte based ..

Have you planned to do the whole game with huc

[nodtveidt]

So far the whole thing is straight HuC code, but I'll do assembly tweaks where required, and they will be.

[touko]

Ok, i have personaly banished all c code (but not huc) because it eats up too many ROM space ...

My caravan  : , this is in 80 ko, and with all huc library for compatibility ..

[TheOldMan]

Very Nice guys.
Glad to see someone else is moving away from trying to do eveything in HuC

Are you guys still embedding the graphics in the program via the #inc functions?

[touko]

Yes, with #incbin for me ..

Glad to see someone else is moving away from trying to do eveything in HuC

Eh,not really, i have said huc library, not C code 

[nodtveidt]

The #incxxx psuedos are the best way for now, unless you have a better method. For stuff that only needs to be loaded once and forgotten about, I'll #incspr in the "bootstrap" overlay and push it into VRAM there so I don't need to bother with it later... less system RAM used later.

[TheOldMan]

"Better" is a relative term. I wouldn't say it was better, just different.  Just wondering if you guys were sacrificing the RAM pages to hold graphics and such.

We ended up with a way to squish BAT/GFX/PALETTE/Chiptunes into an overlay that could be loaded into an empty page of RAM (8K at a time, mind you) then shoved to where it belonged for each level in PP. But I wouldn't say it was easier/better.
We had no choice, there. The PP Game code (Thanks, HuC) came out to 72K iirc. One page too large for a regular CD, but plenty of extra pages for loading from scd. That's one of the things that made pp take so long from the demo version to release.

The reason I asked is I'm debating a way of loading code from overlays dynamically. Thinking about tuokos fighter, I wonder if it might be possible to load the attacks into RAM when the character is selected, instead of trying to embed code for 6 fighters at 10+ moves per guy.

And I'm really disappointed nobody noticed the hacked ipl in pp. I guess next time, I'll have to play an audio track instead of using ADPCM....

[nodtveidt]

The contents of VRAM are preserved between execoverlays so I'll preload lots of stuff. It doesn't matter if the data consumes RAM pages in a "disposable" execoverlay... as long as the RAM isn't wasted in programs where I need as much code space as possible, all's good. I used that technique in MSR, JB, Monolith, and now this project too. All of my productions use the first execoverlay as a "corporate splash" similar to the one you see every time a Sega Genesis cartridge is booted... that program also does ADPCM transfer, preloads anything into VRAM that will never change, and does any other pre-emptive stuff so the main program doesn't have to waste space.

[touko]

The reason I asked is I'm debating a way of loading code from overlays dynamically. Thinking about tuokos fighter, I wonder if it might be possible to load the attacks into RAM when the character is selected, instead of trying to embed code for 6 fighters at 10+ moves per guy.

Only player and current opponant are in level overlay, others are external, and also all levels adpcm .
A dynamic loading will be added for 2 players mode .

And like rover, all stuffs  which are common are preloaded in menu overlay ..

And I'm really disappointed nobody noticed the hacked ipl in pp. I guess next time, I'll have to play an audio track instead of using ADPCM....

An hacked ipl

[Arkhan]

An hacked ipl

Yeah.  There was a discussion about it on our forum.   You were part of it,

[touko]

Are you sure ??
usualy i'am not very aware of this kind of things ..
With startup.asm, ok no problems, but ipl

[MotherGunner]

Awesome Rover!  So you were just joking when you said, "Never again!!!! *Tears*" after MS? =)

[TheOldMan]

We were discussing doing fire effects. I don't remember if the ipl was mentioned or not there.
And yes, a hacked ipl. You can't change some of it because bios does a match check on the code. But if you disassemble the code, you can see how it works. You can pre-load palettes, a BAT, and graphics - the catch being Huc/Magikit doesn't expect those things, so you have to patch the iso to make it work.

What's really interesting is that bios loads 2 sectors (4K) for the ipl - but only about 512 bytes are actually used.
There's an empty space (that has to be all 0's for the check) that you can use for variables because...
you can set your execute address to be -in- the ipl area. And run a splash screen directly from the ipl
For those who understand any of that, bios also stashes the sector number of the ipl for you in the user data area, iirc, so you can load your program after the splash screen is done.

I understand using overlays to load things, and it's not a bad idea. I just don't like the fact that it ends up loading 32K of HuC libraries (most of which it won't use) just to set up vram. And I hate trying to maintain multiple copies of the same basic program because I have to keep re-loading slightly different versions of it...