Basic Questions & Answers thread

So, I'm not sure if this is know or not, but there's actually a Tiger Game.com emulator / debugger thingy on the net that actually runs games.

Sonic Jam is also compatible with it but I'm not sure anyone would like to play it. I would GLADLY link to the emulator, but all the links I found had roms in the zips and I'm not too keen on getting banned. Though I could easily reupload the emulator without the roms if needed.

ANYWAY, since it's an emulator and a "debugger", would it be possible for someone... who knows how to use these stuff to somehow get the levels... ripped from the game? I'm thinking about rebuilding the stages in Sonic 2/3 just to see if an ultimately better engine would help the game at all. Because otherwise they are unplayable (though you can roll forever from what I saw).

 

Sorry about putting two question back-to back, but um...

How to I fix these "Overlapping allocations"? I mean, my assumption is that they're a bad thing, even though my hack seems to run okay.

 

Judging by the use of the word "allocation" and the offset ranges, I'd say this is nothing to do with your ROM, and that this is more of an issue with the assembler itself.

What problem you ask? Well, other than telling you that there's an "overlapping allocation detected", I am as uneducated as you.

 

Does it swing close to the ship like that? If it is swinging, then it most likely means that its just not loading all of the chain links for some reason.

 

The chain links are all loading properly from what I can tell, but with that said, it is rather hard to tell with the Eggmobile and ball overlapping everything... But the main thing that appears to be a problem is that ball isn't orienting itse;f to the eggmobile, it just spawns and then hangs there, until you defeat the boss, then it explodes as it should.

That works then. Either way, my ROM seems to run okay, so I guess there's nothing to worry about.


Edit:
1:Also, I have a couple of questions about the Nick arcade prototype of Sonic 2. Does anyone know what they did to make the title cards not appear, since the object and graphics are still loaded.

Edit 2: For those who were curious, the reason is because they put an rts before every Displaysprite in obj34. derp.

2: Why GHZ's graphics are so buggy? It's really just technical curiosity, but the PLC for GHZ (PLC_GHZ) still calls the correct art.

 

Alright. so I used a disassembly, but when I built it, the output was 1 kb and was just a black screen. I used Hivebrain's Sonic 1 disassembly and typed this into build.bat:

include.exe [s1.bin] [s1built.bin]

s1.bin was the rom I started with. Also, I already split the rom and then built it.

 

While I haven't used Hivebrain's Sonic 1 dissasembly, I have no idea why you're editing build.bat.

What I would reccomend is to use either Project Sonic 1: Two-Eight, or the hg version of Sonic 1, as they are more current.I should have clarified that, my apologies.

 

Okay, so I have a problem. I'm sure someone must have solved this before:



In my hack, Sonic, Tails and Knuckles are S3 style. The Tornado, Tails looks fine in it, so does Knuckles, but Sonic is scrambled. This has been a problem since day one but never bothered solving it. But I need to now. I just can't get Sonic to load properly. Editing the art_tile can get Sonic to look better, but obviously, the Tornado becomes glitched.

Sonic is using his DLC (JmpTo_LoadSonicDynPLC_Part2), and I found that "byte_3AF9C:" are Sonic's animations. Changing these will change the effect of Sonic, but he's still glitched. Tried making the DLC go straight to "LoadSonicDynPLC", but no luck. Anyone know a solution? I swear I've seen hacks with S3 style Sonic and he's fine in SCZ in the plane.

 

There are two things I know:
1: Sonic 2 starts off with the standing pose, while Sonic 3 starts off with walking. Because of this, I'm assuming the DPLC is reading the wrong frame entirely. That's one reason.
2: The other reason is that the Tornado in Sonic 2 is obviously loading the art in a certain way, and Sonic 3's sprites work in their own way. Your best bet on fixing that would be to remake the sprite pieces in the Sonic 3 standing frame in SonMapEd to be consistent with what Sonic 2 uses. That would be the easiest solution.

Hope this is helpful.

Also, a question, mainly aimed at MainMemory; You remember when I asked about extending the zone tables in Sonic 2 to use four acts? It works great, except for two problems, one being a perfectionist caveat, and the other gamebreaking.

1: I filled my game with $12 zones, and while that's all well and good, the real number is $13, because once I got to SCZ/WFZ, which is Zone # $11, I was having problems. The only fix was adding a filler slot before the real Wing Fortress Zone, and while it works, it's not exactly tidy. I had to do this for almost everthing. Do you know off hand anything I can do to make the filler slot not needed?
2: Choosing the 2-player mode crashes the games on Regen. Using Kega Fusion, it runs, but is buggy. How can I update the 2P mode to work with my new Zone system? (and I did test this, the last build where the 2p mode functioned was the one before the act expansion.)

 

Cheers. I know S3 starts with the walking positions, but even they don't even load properly. It's a DLC problem I know, just can't get a work around. So it doesn't matter if I made Mapping frame 1 the standing sprite, because Sonic will still appear scrambled. S3, Sonic standing is mapping 5. Editing "byte_3AF9C:" solves this, but the DLC's are still screwed.

 

The one and only thing I can think of is to do with DMA transfering, the VDP accesses the 68k memory space through a window that is 20000 (hex) bytes big, should the transfer be requested to load data that surpasses the 20000th byte, you'll likely end up with wrong data transfered.

HOWEVER, given that the data for Sonic 3's sprites is setup just so that the individual sprites all fit into the 20000th sections, I'd say this is probably not the case, additionally, the chances are that only one of the frames would result in being scrambled, and I'm assuming that more than one of your frames (that are closely together) are scrambled, so again, unlikely the case.

With only a screenshot, I'm afraid my understanding is limited, sorry.

 

Yeah, Sonic does fit into the 20000th sections. Same with Tails and Knuckles. I can get Tails in the plane perfectly fine with Tails standing on the plane, but Sonic doesn't want to know. I know I'm not supplying a lot of details with just one screenshot, but don't know what else to show. Could show the ObjB2 data (Tornado object), but that's pointless as anyone could look it up. I'm hoping someone who sees this has solved it for their hack and can share their secret. Thanks for the reply though.

 

Honestly the only thing I can think of is that $11 is the total number of zones in stock S2 (SCZ is $10), so perhaps some code thinks $11 is an invalid zone number?
As for 2P mode, I cannot help you. That's usually the first thing I remove from my hacks.

 

1: You are most likely either not using the Hg disassembly or not consistently using the zone constants it defines: there is a lot of behavior coded for specific zones in the game that uses their IDs; the Hg disassembly uses symbolic constants for this, which makes reordering the zones relatively simple, but earlier versions (such as Xenowhirl's 2007 one) weren't as thorough as the Hg version and can bump into issues when you try.
2: Look into the forum for my address error debugger, put it into your hack, build and test it: crashing in Regen and working (even if buggy) on Kega or Gens is a good sign that the problem is caused by an address error. Now, it could be something else, but ruling out a potential problem is always good.

If you open SonMapEd and open Tails' art/mappings/DPLC, you will see that he uses 2 2x3 sprite pieces in stock S2 for the Tornado frames (1, 2, 3, 4, $10. If you do the same for Sonic, you will see that stock S2 Sonic uses 2 sprite pieces (a 2x3 for the head, a 4x4 for the rest of the body) for the Tornado frames ($2C, $2D, $2E, $30). Now if you look at the Tornado mappings and DPLC, you will notice it uses a single 2x3 sprite piece for the pilot's head. The first 4 frames expect the pilot's art to be in Tails' VRAM, the last 4 frames expect it to be in Sonic's VRAM. Thus, the first set of 4 frames are for Tails and the second set of 4 frames are for Sonic.

Finally, take a look at S3 Sonic and Tails in the corresponding frames. Tails now uses 1 3x4 sprite piece for his 'Tornado' frames, but Sonic now uses a 1x3 sprite piece for the top of his head and a 4x4 for the rest of his body. You probably fixed Tails' mappings for the Tornado, but didn't fix Sonic's adequately (or at all).

 

Ah, so it's about the mapping size, that's why changing the animation script did bugger all. Taking you're advice, I investigated, and had to redraw some of Sonic sprites, rearrange mappings so it wouldn't affect Sonic in normal games, and fixed it:




Cheers for the advice mate, greatly appreciated.


EDIT: Forgot to mention. I never did fix Sonic (obviously) but I never fixed Tails either. But because Tails' S3 style is extremely similar to S2, there was actually no difference to the mappings and art that was being used. So, he was already fixed. I don't know how the fuck Knuckles was already fixed, but meh =P

 

1: So, what you said reminded me of something that ended up being the problem. My bad, I'm an idiot. Basically, I have merged Sky Chase Zone and Wing Fortress Zone into one zone in my hack. In the end, this was the problem:

Code (Text):

1. sky_chase_zone zoneID           $11
2. wing_fortress_zone zoneID   $11

If I change it to just WFZ, it may fix it?

I deleted the Sky Chase Line, and changed all the references to Wing Fortress Zone act 1, and it fixed not only the filler zone, but also the addressing errors I was having in my assembly before.
so I guess my hack was trying to make two different zones in the same slot, or something like that.

2: I installed it into my hack, and gotan error message, but I just want to point out, there's one thing I don't understand:

What exactly do you mean by "the line invoking asw/asl"?

Edit: Nevermind, I figured it out.

Thanks a lot! I haven't fully tested it yet, but this tool will make things so much easier!

I finally got 2P mode to load.
There is however... Work to be done yet.

 

Really? I looked into Game.com emulation just a few months back, and what I found was that there was basically only one guy out there who had one, and he refused to release it because "muh morals!" (Even though it's a long dead system that you can't purchase anymore, and it was a commercial failure even when it was still around.)

 

I uploaded it without the roms inside: https://dl.dropboxusercontent.com/u/52685605/Game.com%20emulator.7z
I found download links for this at multiple places, so I don't think there's any moral stuff about this anymore. If there is, I'll delete the link.

You go to Window>Open Disasm Window>File>Load BIN File>File>Load Kernel>Full Kernel and click the Run button. A new window will pop up with the Game.com menu and if you select the game, it'll load the bin file you selected (in our case, Sonic Jam). You might need a bios file and of course the game for it. It comes with debugging tools as well, that's why I'm raising this question.

 

I've got a question about ASM68K.

This is how I'd normally include a resource in a project, for example a palette:

Code (Text):

1.  
2.   incbin "palettes\myPalette.bin"
3.  

I'd like to make this into a macro, like this:

Code (Text):

1.  
2. Palette: macro filename
3.   incbin "palettes\"+\filename
4.   endm
5.  
6. ;include a palette
7.   Palette "myPalette.bin"
8.  

But it doesn't appear to let me concatenate a string for incbin. Is there any way around this at all?

I know there are functions like filesize() which are very hard to find documentation for. Is there some kind of string() function, or filename() or something that might help me out?

 

These manuals are indeed hard to find, but I think this one should work: http://koti.kapsi.fi/~antime/sega/files/SATMAN.pdf

For the include issue, let me post some code from vladikcomper's MegaPCM:

Code (ASM):

1. IncludeDAC macro Name,Extension
2. \Name:
3.     if strcmp('\extension','wav')
4.         incbin  'dac/\Name\.\Extension\',$3A
5.     else
6.         incbin  'dac/\Name\.\Extension\'
7.     endc
8. \Name\_End:
9.     endm

Using double instead of single quotes doesn't seem to matter. I always use double quotes and they worked fine in ASM68K.