Basic Questions and Answers Thread

Well, it IS the palette for super tails. You are obviously not understanding something or doing something wrong.

This is that palette loaded into hivepal:

 

Its alright Mike B.Berry is helping me

 

ok I have a weird problem when transfroming into super sonic in HPz after transforming in about 2 seconds the game crashes. I checked and it does only happen in HPZ, but when I transform into super tails in HPZ the game doesnt crash why would this be? please help

 

Quick question if I were to give each character there own path, where in the S3K asm file controls the start pos for Sonic/Tails and Knuckles? From there I think I will be able to port it to Sonic 2.

EDIT: I found it but its in bin files this is going to be harder than I thought :/

Edit: Ok I got it! but for some reason Sonic doesnt start in the beginning of the act he starts at the end of the act but Knuckles Starts in the right pos. This is what the Loc looks like now.

loc_C17A:
                   move.w (Current_ZoneAndAct).w,d0
                   ror.b #1,d0
                   lsr.w #5,d0
                   lea (WrdArr_StartLoc).l,a1
                  cmpi.w #3,(Player_mode).w
                  bne.s loc_C196
                  lea (WWrdArr_StartLoc).l,a1
                  moveq #0,d1
                  move.w (a1)+,d1
                  move.w d1,(MainCharacter+x_pos).w
                  moveq #0,d0
                  move.w (a1),d0
                  move.w d0,(MainCharacter+y_pos).w

EDIT: Alright bug gone the answer was right in front of me.

EDIt: Shit now its only keeping track of Knuckles act 1 EHZ position and loading him for that position in every zone.

 

Would anyone like me to make a guide on this and admins. and staff would you be fine with me making one?

 Edit :Never mind. I found a bug in the programming

 

Judging by the way it tests the game mode right before the direct routine that branches into the loading array, then loads Knuckles' loading information, Sonic and the other characters follow his array, instead of their own. Now EHZ is the exclusion solely because their starting positions remained the same, whereas the other zones's positions have been tampered with. Am I correct?

 

Dunno how simple this is, but how do you remove the water from labyrinth?

 

Let me try to guide you to the solution. Something that happens only in one zone must be the result of a comparison in the code (e.g. a cmp or cmpi instruction). You can see it as "IF zone = Labyrinth THEN do something". Given that the zone is stored in RAM location FFFFFE10 and Labyrinth's ID is 1, look for

Code:

cmpi.b	#1,($FFFFFE10).w

And see what happens after that (note: there is more than one, and some are completely unrelated). While I never removed the water from there by my own, I already found a few places in the code which looks quite related to it. If you won't find a solution by your own in the next hours I'll give you more advices. Good luck!

 

Thinking about it, would it be easier to just lower the water to the bottom of the screen like in angel island?

 

If you do that, just remember that the water level is dynamic so there are still a few routines you should take care of. Some are still near one of the comparision instructions I mentioned before.

 

For some reason now SCZ objects dont load but the rings and layout do and I checked the object load routine and it does say its loading the SCZ project objects data, what could be the reason for them not loading at all?

Edit: Opened the project file too and the objects are still in there. Also took a clean levEvents_SCZ routine from a clean asm file and placed it in my asm file.

 

And still no objects loading in the game?  What emulator you using too?

 

Correct and I checked that I don't think it's the emulator because the same thing happens in Kega and Gens.


Edit: Did use to us Kega but then Mike B Berry told me its not a good emulator to test on so I now use Gens, plus after he added Water Ripple Effects, CPZ and ARZ would freeze at the title card screen in Kega.

 

Wha?  Where did you get that info from?  When people play my hacks, if they report a bug from Gens, I don't want to know.  Kega, Regen or real hardware, I'll listen.

Regen is the best IMO, otherwise, Kega.  All others I don't bother.  I only use RecordGens for recording videos.  And MD.emu for my android phone.

Anyway, when porting the ripples, you said it freezes in Kega?  And not in Gens?  This means if you put your hack on real hardware, it will also freeze.  Regen and Kega are the closest emulator to real hardware.  Gens normally fixes the issue itself, that's why it works with that.  So this more than likely means you've ported the ripples wrong; and does need fixing.

Anyway, the objects.  This is weird.  The pointers are definatly right?  Maybe you've put too many objects?  Not so sure.... any graphical glitches?

 

Gens as itself is terrible, but GerbilSoft made Gens/GS for a reason, which is having a Gens that doesn't suck. And my god, it's good.

 

Yes they are pointed correctly and no glitchs when entering SCZ the backround is still correct as well. Oh and I am using GensGS.

 

whilst on the subject of accurate emulation what do people think of fusion? I test mainly on my everdrive cart but usually run it in fusion first? any tips or advice? other than gens is shite as I think the whole community knows this

 

I've been using Kega all the time, although it's far from being accurate in some parts.
 
To be fair, Kega isn't really designed for developing and debugging homebrew. By far, Regen is the most accurate emulator and Kega isn't even the second accurate emulator nowadays (I believe GensGS is better in emulating all those hardware quirks now). However, Kega's emulation is nearly perfect despite a lot of inaccuracies - it can emulate some exotic VDP tricks that even Regen fails at. How is that possible? Let me explain.
 
You see, Kega isn't designed for developing purposes, it's more oriented for emulating a ready production (and it does quite good with it). If there is a certain hardware quirk or rare bug that none on known games/programs relies on - Kega won't bother emulating it. This sort of inaccuracies is intentional. Some hardware features are ignored in a smart way: as long as it doesn't affect perfect game emulation per se.

Here is an example: you have to set a certain system port to initialize hardware correctly. This is a standard routine and you have only one way - set the port or else hardware won't run. But this action doesn't help in emulating game itself at all. This is where Kega comes with intended inaccuracies: it won't emulate this, just because this is useless in terms of emulation - you don't actually have to set this port to run emulator correctly, this is all hardware quirks. So Kega just assumes it's everything okay with this port, it won't emulate hardware crashes just because of this quirk. But when when it comes to emulating your game's sound and video, Kega will do its best to produce perfect and most accurate results. I'm pretty sure most of inaccuracies were intended to provide the fastest emulation possible - missed features simply optimize it and give less times less CPU load.

To sum it up, Kega wasn't really intended as your crash test emulator, so I'd recommend using Regen for these purposes. But as I mentioned earlier, Kega is really good in VDP emulation, it can handle some crazy VDP tricks that even Regen fails to emulate.

I've been working with Kega for years and I've figured out a lot of missed features. If you woder, here's the list of most noticeable ones:

• No Address Error emulation. This the biggest and the most insidious problem. Everything works perfectly, but when you try it on real hw... Most of emulators don't emulate it to optimize CPU emulation. As the result, you don't see it, you don't know it. This is why the issue is really insidious, apparently it became the most common reason why your perfectly working hack suddenly refuses to work on hardware. The only emulator I know that emulates it is Regen (I heard GensGS now does that too, didn't check).
• Accessing odd memory addresses. Since it has no Address Error emulation, Kega allows you to read or write words on odd addresses. Here is where another insidious problem hides. Both Kega and Gens allow you do this, however, they handle accessing misaligned addresses differently. Gens applies a bit mask to ensure the address you're accessing is even. For example, if you're writing a word to $FF0001, Gens will write to $FF0000 instead. Kega, in turn, will write data exactly to $FF0001, which seems more legit than weird alignment that Gens does. So beware. If you're mistakenly accessing odd addresses, expect your code to behave totally differently in Kega and Gens.
• No Z80 BUSREQ emulation. Recently I've discovered that Kega simply doesn't emulate Z80 bus request and release - it always allows you to access Z80 memory area whether you requested it or not. I admit this isn't really important in terms in emulation, but this won't help to detect missed BUSREQs if you're debugging the code. Other emulators, including old Gens seem to emulate this properly. If you accessing memory area of working Z80 without BUSREQ, you won't be able to write or read properly. If you're waiting Z80 to provide the bus and you accidentally pushed it into reset state, you'll end up in a dead loop. None of this will happen in Kega.
• Z80 isn't stopped on DMA when it accesses 68K. Nah, this would be really heavy to emulate, even Regen doesn't go for it.
• No cycle stealing emulation on accessing 68K memory. Z80 accesses 68K by so-called cycle stealing. It requests 68K to transfer a byte from a certain address, which takes 4 cycles from 68K side. 68K can be requested when it finished processing the last opcode, it happens between the opcodes. The Z80 has to wait 68K to respond. Again, this is way tricky to emulate, and none of games attempt to have a full 68K and Z80 synchronization relying on this.
• Problem with restoring YM register port when loading a savestate. Found that one out when playing a digital audio with Mega PCM in Sonic 1 Megahack. The music stopped playing after loading a savestate until YM register port is updated. Looks like it's nulled after loading a savestate. I think it's an issue with savestate format. Same happens in Regen, if I'm right, because it uses the same format. This won't lead to any serious problems though.
• YM busy state isn't emulated. On real hardware, you must ensure YM is not in the busy state before accessing it from 68K side. As I remember, even Regen doesn't handle missed YM writes if the chip is busy at the moment, on the hardware, it causes some sound distortion.

 

A problem I had when using Regen was without warning the program would shut down, for example I minimized the window once I did that it did minimize to the toolbar but then when I pressed it again when I wanted to maximize it, it disappeared.


I use Windows 7 so I doubt it's my computer. I could be wrong though.


Edit: Also shuts down while in play