Concerning the previous query with the rings, albeit with Sonic 2. From what I see the routines are almost the same, but when I apply the same fix, it doesn't seem to work. Any idea what is altered here? Also a more complex query. Is it possible to change the character's life icon when they turn Super? I know there are routines that recognize patches for a different character's life icons, but have no idea where and how it knows when to load them and if it can be done mid game.
For the rings, Sonic 2 has a special rings manager that handles the rings that appear in levels, the actual ring object is only used as part of the code for the scattered rings afaik. For the life icon, if you wanted to do that, as far as I know you would have to have uncompressed copies of both the normal and super life icons (not the text area, just the picture) and initiate a DMA transfer to the VRAM location of the life icon graphic when you change forms. Depending on your disassembly, the function will be called DMA_68KtoVRAM, QueueCopyToVRAM, QueueVDPCommand, Add_To_DMA_Queue, or QueueDMATransfer.
I'm inexperienced with DMA transfers with art. Could you explain a bit further? One more thing (I know, I know...), I'm having an oddity in S2 with a jump dash ability, I've made a branch so that it goes higher as Super. The branch doesn't seem to work when jumping, but will if you press when walking off a ledge/spring/object,etc (ie. it doesn't work in MdJump stipulations but does in MdAir ones). I checked both routines and they are the same (the ASM even notes this). Anyone have any idea what would cause this?
It's only four tiles, and you're not intending to change the art every frame: just once in a while when they turn Super or back. As such, I don't think uncompressed art is necessary. If you're using S3&K, just use Moduled Kosinski compression and: Code (Text): lea (ArtKosM_NewLifeIconHere).l,a1 move.w #$1234,d2 ; replace with VRAM address for the life icon jsr (Queue_Kos_Module).l If you're not using S3&K, if you have a free $80 bytes of RAM (enough for four tiles) you could do a KosDec to RAM then DMA that RAM over (which I believe is basically what Queue_Kos_Module does, except it already has a buffer of $1000 bytes allocated, and takes care of making sure it doesn't lag up the game if there is a lot of art to load, etc.). Or if you want to be really fancy, find a spare $1000 bytes of RAM and port over the KosM code so you can speed up other things too :v: Edit: Forgot to actually answer the question about DMA... Depending on your disassembly, you may or may not have some code that looks like this: Code (Text): ; makes a VDP command vdpComm function addr,type,rwd,(((type&rwd)&3)<<30)|((addr&$3FFF)<<16)|(((type&rwd)&$FC)<<2)|((addr&$C000)>>14) ; values for the type argument VRAM = %100001 CRAM = %101011 VSRAM = %100101 ; values for the rwd argument READ = %001100 WRITE = %000111 DMA = %100111 ; tells the VDP to copy a region of 68k memory to VRAM or CRAM or VSRAM dma68kToVDP macro source,dest,length,type lea (VDP_control_port).l,a5 move.l #(($9400|((((length)>>1)&$FF00)>>8))<<16)|($9300|(((length)>>1)&$FF)),(a5) move.l #(($9600|((((source)>>1)&$FF00)>>8))<<16)|($9500|(((source)>>1)&$FF)),(a5) move.w #$9700|(((((source)>>1)&$FF0000)>>16)&$7F),(a5) move.w #((vdpComm(dest,type,DMA)>>16)&$FFFF),(a5) move.w #(vdpComm(dest,type,DMA)&$FFFF),($FFFFF640).w move.w ($FFFFF640).w,(a5) endm ; tells the VDP to fill a region of VRAM with a certain byte dmaFillVRAM macro byte,addr,length lea (VDP_control_port).l,a5 move.w #$8F01,(a5) ; VRAM pointer increment: $0001 move.l #(($9400|((((length)-1)&$FF00)>>8))<<16)|($9300|(((length)-1)&$FF)),(a5) ; DMA length ... move.w #$9780,(a5) ; VRAM fill move.l #$40000080|(((addr)&$3FFF)<<16)|(((addr)&$C000)>>14),(a5) ; Start at ... move.w #(byte)<<8,(VDP_data_port).l ; Fill with byte loop: move.w (a5),d1 btst #1,d1 bne.s loop ; busy loop until the VDP is finished filling... move.w #$8F02,(a5) ; VRAM pointer increment: $0002 endm If not, it should be safe to copypaste in the above. Then, you can just write something like Code (Text): dma68kToVDP $1000,$2000,$800,VRAM where $1000 is the source location in RAM, $2000 is the destination location in VRAM, $800 is the number of bytes to copy and the last argument tells it to write to VRAM as opposed to CRAM or VSRAM.
So, I've been thinking of devising a model pack for Garry's Mod, consisting of the E-100 robots, ripped from Sonic Adventure DX. Before I went through all the trouble of getting Sonic Adventure DX on my operating system and trying to find a way to extract the models, I thought I'd just ask you lot if you had access to any of the models already, as it would save me a lot of time. I felt as if this didn't need it's own thread. I'm not exactly sure if there are any big visual differences between the E-100 models from Sonic Adventure and Sonic Adventure DX, so it doesn't really matter which version of the game they were ripped from. I've searched around and have only found E-102 Gamma, which is a start, I suppose. Anyway, does anybody have the others?
I found them at http://www.models-re...dxdirectorscut/ in the "Bosses" section. Hopefully that helps you.
Hey, thanks! Unfortunately, those aren't exactly what I'm looking for. You see, the models on there are the versions of the robots before they got reconstructed. I really should've mentioned that I was looking for the reconstructed versions. Thank you for looking, though.
Weren't they basically recolors/retextures of Gamma (or had minimal changes, like two guns instead of one etc.) anyway? It's been a while, so I don't quite recall.
Yes. E-101 Beta had two guns from the start, though. He was the only structurally different one out of the original bunch. By the time E-102 Gamma got to destroying them, however, they'd all gotten redesigned. I'd be fine with OBJ.
Since you didn't really specify what you wanted, I just ripped almost everything, in both formats because why not. Download
I'm looking to do some dialogue replacement in the Steam version of Adventure. I've already started adding in new voice clips, but I'd like to be able to change the subtitles to match as well. I know they're basically written in plain text in the raw code, but as a total neophyte to this whole hacking thing, I have no idea where to start and I don't want to risk screwing up the EXE file in the process (unless the subtitles are actually stored in a different directory, in which case I'm even more lost). Is there a specific tool I can use to simplify the process, or would someone be willing and able to walk me through it?
Unfortunately, while tools that can easily do what you want exist, they only work on the 2004 version. The data's exact format is complicated, but you can edit the raw text as long as it stays about the same size or smaller (you may be able to go a bit bigger, as long as there's at least one 00 byte between it and the next piece of text).
Hmm, I was afraid of that. Ah, well, maybe I'll see if I can't find a copy of the '04 version to mess with. On a similar subject, I was hoping to do the same with Adventure 2, but putting aside the subtitle conundrum for the moment, I'm having difficulty with the voice files. I've tried three different programs to unpack the AFS files, then converted the resulting ADXs to WAVs, but they always come out as a static-filled mess, unlike those of DX. Is there a particular conversion tool or method I should be using to unpack and repack these?
Does anyone know how to program sprite collision in S3+K? I've made a new object in the game. I've given it a $40 for the collision flag byte ($28) and made a branch to the collision response data like so: Code (Text): jsr (Test_Sprite_Collisions).l I then added branch data for what seems to be the enemy and monitor coding like so: Code (Text): loc_100BC: cmpi.l #Obj_Laser,(a0) ; is it laser? bne.s loc_100BC_Sally ; if not branch. cmpi.b #0,$20(a0) ;is it correct animation? beq.w loc_1012E_NICOLE ;if so branch. loc_100BC_Sally: btst #1,$2B(a0) bne.s loc_100F0 cmpi.b #9,$20(a0) beq.s loc_1012E cmpi.b #2,$20(a0) beq.s loc_1012E cmpi.b #2,$38(a0) bne.s loc_100F0 cmpi.b #1,$2F(a0) beq.s loc_1012E cmpi.b #3,$2F(a0) beq.s loc_1012E bra.w Touch_ChkHurt ; --------------------------------------------------------------------------- loc_100F0: cmpi.b #1,$38(a0) bne.w Touch_ChkHurt tst.b $2F(a0) loc_100FE: beq.w Touch_ChkHurt btst #6,$2A(a0) bne.w Touch_ChkHurt move.w $10(a0),d1 move.w $14(a0),d2 sub.w $10(a1),d1 sub.w $14(a1),d2 jsr (GetArcTan).l subi.b #$20,d0 cmpi.b #$40,d0 bcc.w Touch_ChkHurt jmp loc_1012E loc_1012E_NICOLE: addq.b #2,routine(a0) loc_1012E: tst.b $29(a1) beq.s loc_1019A neg.w $18(a0) neg.w $1A(a0) ... It doesn't quite work. It only hits enemies half the time and won't hit other objects like monitors at all. Any idea what I'm doing wrong? I should perhaps note I'm not positive it's implemented correctly. The projectile appears behind a lot of objects and foregrounds instead of in front. EDIT: Okay scratch that, I (as in Flamewing :P) managed to work out how to program it to collide properly, however I'm still having problems getting it to work on other objects like monitors, would the correct form of branch be this? Code (Text): cmpi.l #Obj_Laser,(a*) ; is it laser?
I've recently checked the folder where I installed Sonic Heroes. And I've noticed, that in SONICHEROES\dvdroot\text there are two types of files: .mtx and .utx. Is there any program/relatively simple way to edit their content? I was recently wondering about trying to make polish translation of the text in the game, especially since I've ended it whole and there is not so much of text (or at least), so it would be good for first "amateur attempt". And by the way - if there is such possibility, is there any way to change the font (probably leaving the current font and avoiding polish letters (like "?" "?" or "?") would do the trick, but if there is some way, I would use it to make possible using polish letters. For now I would like to simply replace the content of one of the "language files" (the english one, to be more specified), without changing its name (I think that it would allow me to avoid some troubles, which could occur if I would like to rename the language pack/language choosen in the launcher).
I'm in need of help with an issue I have with a mod I'm making for Generations. Should I post it in the Generations Hacking thread that already exists, or make a new one? I would assume I'd be posting it in the pre-existing thread, since I don't see a lot of individual threads, but I figured I should ask first, rather than jump into a massive thread as a newbie user.
Good day, everyone! Can someone please explain how does collision mask work in classic games? To be specific, I talk about getting hit by hazards/badniks, killing badniks, collecting rings, interacting with tiny gimmicks (like bungees in AAZ or baloons in CNZ). Does sonic have a separate collision mask which's size depends on sprite size (for example Sonic not getting hit by orbinaut's spikeballs when crouched) or the game just detects collision with character sprite itself? Is the collision mask circular or rectangular shaped? Does the game use a separate collision mask for collisions with hazards/collectibles or just a single one? Thank you in advance!
The classic Sonic games and really most games of the era usually use very basic and cheap ways to deal with collision. That being said it does not mean it is bad, but it is very simple. Lets imagine Sonic's standing pose. The sprite is shown relative to Sonic's X and Y positions. Not all of the sprite is on positive axis however, which allows the hitbox be more "accurate" or fair. While the hitbox is calculated from X 0 Y 0, the sprite is usually shown somewhere in the negatives. This allows to not have to make exceptions for all sprites, especially sloped running ones, which use the same collision hitbox as standing sprite for example. In fact, in original Sonic 1, there is only two hitbox sizes, one for jumping/rolling and spinning, and one for everything else (or at least from what I remember this is the case), while Sonic 2 and 3K adds few different sizes, for example Tails as he is shorter. In Sonic 1 all the hitbox sides, as with floors, walls and ceilings, so with the objects is hardcoded, while in Sonic 3K it is controlled by value in RAM which allows easier change. The way the collision hitbox dealt, is the game checks for object RAM for each object with collision value of not 0, and then gets its size and position, and does simple calculations to check the two overlap at least slightly. Each object has custom size which is often the size of the sprite itself. Then the objects have a collision value, which determines how they act. Most objects are made to just hurt Sonic on touch, unless he is rolling. However some have special behaviors, such as monitors break if Sonic rolls into them, or caterkillers scatter, and some objects simply increment the routine counter where the object itself determines what to do. Or even in some cases, the collision is hardcoded to the object itself, such as spikes, which are actually a solid object, which is a common way to make Sonic push against an object and stand on it. Objects such as springs and spikes use this to bounce or hurt Sonic when standing on top of them or push against them. Here is a quick mock-up of how the game approximately process the hitboxes: