Basic Questions & Answers thread

Would anyone know where the Sonic 2 Level Select & Menu Background is stored? I can't seem to find it anywhere no matter how hard I looked

 

Relative to the GitHub disassembly
The function itself is MenuScreen. Which simultaneously handles the options screen and 2P menu stuff, with conditional checks based on the scene ID.
"art/uncompressed/Sonic and Miles animated background.bin" for the tiles.
"mappings/misc/Sonic and Miles animated background.eni" for the mappings.
"art/palettes/Menu.bin" for the palette.
Frankly I'm not entirely convinced you looked hard enough though. You seem to jump to this thread the moment you hit a small stone in your path.

 

Anyone know where I can find references to additional fixes to the stock Sonic 1 Sound Driver? Example: https://sonicresearch.org/community...s-bugfixes-for-the-sonic-1-sound-driver.3970/

Yeah... I know. Stock Sound driver... :P
Just trust me... I have my own reasons.

 

Is it possible to change the chunk size for 256 to 128 in the Sonic 1 disassembly?

 

Yes.

 

It is a LENGTHY process to undertake. Unless you are already well underway in your current project, I would recommend starting with the disassembly on the page linked by Kilo.

 

I was curious about something, how feasible are 192 chunks?

 

Would be trickier, because it's not a power of 2. With powers of 2, you can do some basic bit shifting to retrieve block data at a specific position. With something like 192, it would just add extra complication. Not impossible, but probably not ideal for performance.

 

Frankly I just wished there was a ROM efficient method of pulling off levels constructed from 16x16 blocks to achieve the complexity of Mania...

 

Maybe 64x64 chunks then? How much memory would it consume to split a Sonic 1 level into 3x3 chunks per chunk? The idea here is to create a loosely 75% scale version of Sonic 1 levels.

 

As you reduce the chunk size, you increase the layout size, and you reduce your overall chunk space range. Because $100 64x64 chunks will hold less visuals than $100 128x128 chunks. Your layout will go from $1000 bytes to $4000 bytes, as you need x4 as much layout data to account for the same 4000x800 level size. You can rectify chunk space range by using a larger data type in the layout, say words instead of bytes, to allow $10000 64x64 chunks, but then you increase the layout by another x2 to $8000.

128x128 has proved to be a reasonably balanced chunk size, it compromises between size and flexibility quite well, go too far one way, you'll limit flexibility, go too far the other way, you'll cost yourself space.

 

move.l #$40000000+((VRAM_Plane_B_Name_Table+planeLoc(40,3,22)&$3FFF)<<16)+((VRAM_Plane_B_Name_Table+planeLoc(40,3,22)&$C000)>>14),(VDP_control_port).l
why is AS treating this as a range overflow? ((VRAM_Plane_B_Name_Table+planeLoc(40,3,22)&$3FFF)<<16)+((VRAM_Plane_B_Name_Table+planeLoc(40,3,22)&$C000)>>14) should be a word value, or at the very least fit into a longword...
I'm using Sonic 2 AS, if that's any help.

 

Put "VRAM_Plane_B_Name_Table+planeLoc(40,3,22)" in its own brackets.

AND operation has priority over PLUS in the order of operations.

 

this didn't help either, but I'm trying a solution I realised I could have done instead that resolves the need for any direct VDP shenanigans. thank you for bothering to reply though!

 

I haven't been able to find the specific rule preventing doubleposting (though I remember reading it and there was some exception clause like "don't doublepost unless it's absolutely necessary" or something, so hopefully my memory serves me right and I won't get trashed).
I've got a problem I can't figure out: I'd tried to implement the Boing-o-Bot enemy from Sonic Chaos into Sonic 2 on top of the Motobug code from Sonic 1, but I found that the spring (which I made its own sub object) does not track the main object's position correctly (the X and Y positions seem to be arbitrary). the problem starts either at the label Moto_Init or under Moto_Spring .
clownmdemu reports the Y positions as clearly invalid. the only issue is I don't know where these are coming from. is it the movea.w instruction at fault or something?

have a link to my s2.asm file (search Moto_Init: , as this file is too large for Github to display)

 

I don't have an answer for you at this moment, but I just wanna mention that that rule only really applies if barely any time has passed since your last post or if you have nothing new to say. In your case, it's been about 2 weeks since your previous post, and you are asking a totally different question, so you'll be fine.

 

I can't see anything in particular that would make it not work, just minor spots that could be optimized. But why not just bake the spring sprite into the enemy rather than using 2 slots in the object table for a single, simple enemy? You could effectively leave the Motobug's code entirely unchanged and just tweak it's collision response type to be that of like Yadorin, but instead of hurting you from jumping on top of them, you instead make the player spring up.

 

oh, I forgot about Yadorins, I'll have to look at how they're implemented. thank you!

 

I have a question related to the Mega Drive's VDP.

Can X and Y values of sprites ever be negative? After all, if the coordinates are outside the screen, they're still positive because the canvas is bigger than that. That's why 128 is always subtracted from them to get the screen coordinates.