71157690 visitors

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nightcrawler

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 73
Site Talk / Re: Credits Section
« on: October 16, 2013, 06:32:52 pm »
Defaulting to 5 is simple enough if it makes that big of a difference for you. No noticeable difference on my machine though. Done.

ROM Hacking Discussion / Re: Square SNES SPC Engine
« on: October 16, 2013, 06:20:18 pm »
That commented SOM dis-assembly sounds like something useful to add to the Documents section on the site. There's not too much in the way of commented SPC code there.

Site Talk / Re: Credits Section
« on: October 15, 2013, 08:20:25 pm »
Indeed it would be easier, but short of having a monumentally long form, there's no way to do that at present. It would be useful if you were to describe what you would specifically expect of the form or user interface mechanism that would accomplish this. Mock-ups or example from another site are useful too. Hopefully, RHDN's form interface can be redesigned or improved accordingly sometime in the future.

Site Talk / Re: ROM Hasher
« on: October 15, 2013, 08:13:36 pm »
Understood. My perspective was that of the worst of the RHDN userbase who will be lucky to even be able to download and start your application, let alone get proper usage out of it! ;D Those people probably need to be told what to do or they'll just be sending you requests for help to answer! ;) Just something to think about.

Site Talk / Re: ROM Hasher
« on: October 13, 2013, 06:18:35 pm »
Nice work. It looks good to me as far as my area of expertise goes. I might suggest a small user interface change though. Does it make sense to allow loading of the 'Patched ROM' first before loading the unpatched ROM? It seems a little confusing and/or less intuitive to me doing it that way. I'd say maybe block that out until you've already selected an unpatched ROM/file. It makes sense going the other way around because the unpatched file hash is what is most required. Then, when you add the patched ROM it simply tacks on the patched file lines too as extra.

The next thing that I think is important to try and figure something out for some of the disc based systems, at least for PS1 and PS2. Unfortunately, I can assist much with that. I think you can get the serial number from a file in the root of the ISO image. Or, perhaps there is a database based on the EXE hash. I don't deal with those platforms much, so hopefully someone more knowledgeable about it will chime in.

Newcomer's Board / Re: Writting a SNES game
« on: September 25, 2013, 06:48:32 pm »
Is it possible to store memory for tiles off screen, and then scroll the background removing the need to load in positions into 2116 and then the tile into 2118?

Indeed. You would store the tiles in VRAM. It's up to you, the registers, and tilemap which of those tiles gets displayed on screen at any given time. Furthermore, the background layers can be larger than the visible screen, so things can always be stored off screen that way too. There's several different ways you can do a scrolling screen. You'll want to do it with as little per frame loading to VRAM as possible though since available vblank time is probably the most limiting factor on the SNES other than the CPU speed.

I highly advise anyone in your position take a look at [ur=http://www.romhacking.net/utilities/274/]VSNES[/url]. It's a fantastic learning tool for newcomers to start to understand how the screen is put together and how the hardware registers work. You can tinker with VRAM, tilemaps, registers, layers, sprites etc. to your hearts content figuring out how it works quickly and easily.

General Discussion / Re: Hip Hop vs. Rap
« on: September 25, 2013, 06:39:53 pm »
Perhaps this an appropriate time for:

http://www.youtube.com/watch?v=rPEt4l7l41M  ;D

Programming / Re: Getting Started on a VWF?
« on: September 15, 2013, 10:13:48 am »
Congrats. :) That sounds like a reasonable approach to me. To clean it up, you'd probably want as few game hooks as possible. So, you can think about how to more smartly integrate it with the game code. Also things like if you're still using your new DMA transfer, perhaps you want to figure out how to get the game's original transfer to handle what you want. Or, sometimes it's a cleaner approach to disable several of the games routines and replace with your own replacements. There's more than one right answer. ;)

I'd say get it working perfectly and worry about optimization and cleanliness later.

Programming / Re: Getting Started on a VWF?
« on: September 14, 2013, 10:12:37 am »
You can only transfer to VRAM during vblank or it will fail. Do a quick test and try it on ZSNES and it will probably work as-is.

You'll need to wait for vblank by using register $4212 and bit 7 (vblank flag).

Something like this should get you going right before your DMA code starts:

Code: [Select]
lda $4212
bpl waitforvblank

For actual final code, you'd probably want to do some fancier code to either wait for a fresh frame, or determine if you're already in vblank and how much time is left to know if you complete the transfer. These types of things will avoid periodic timing glitches that could occur with the simple check. That's a topic for another day though!

Agreed. It should be OK to do this and it should work fine. As mentioned, the banks are operands of the instruction and the instruction merely executes and jumps back to itself to execute again until complete.

So, it's no different than any other opcode as far as being interrupted and using the same instruction within your interrupt handler.

Programming / Re: Getting Started on a VWF?
« on: September 13, 2013, 08:26:30 pm »
The only way to tackle anything complex is to break it down into simpler achievable steps. Try step one (Basically your step 2).

Change the text routine to figure out where to pull a character from ROM. Debug that routine until it works as expected and you have the correct location at 7E0200.

If you get that done, try the next small step which is to retrieve that character from ROM and store in RAM somewhere. Put that code immediately after. Again, debug until you get it right.

Ok, so now you know you can pull characters from ROM and write them to RAM. Now you need to work understanding how to transfer that data to VRAM. Don't worry about what the game does. Just slap a DMA transfer or a manual transfer immediately after the code you wrote to store the character in RAM. Put a infinite loop right after that so it freezes so it doesn't even advance. Then debug this code until you can successfully figure out how to transfer a tile to VRAM yourself! You can debug this by seeing if the DMA triggers correctly in Geiger's debugger, taking a savestate and examining it in VSNES, or checking VRAM in an emulator that might allow you to view it.

Lastly, directly after your transfer (continue to forget about the game), you'll want to go for some tilemap changing code to reference the tile you just placed in VRAM. You can check for a successful tilemap change using savestate, VRAM hex viewer etc.

The idea here to to take the game out of the equation so you understand the fundamentals. The way it is now what the game does is confusing you on top of struggling with the fundamentals. So, separate the two for now. By the end of this exercise you'll have figured out how to retrieve a character from ROM, copy it to RAM, and then get that into VRAM. Then change the tilemap to reference your character on screen.

Finally, when you've figured out the basic mechanics of printing a letter to the screen, you can worry about what the game is doing.

Site Talk / Re: ROM Hasher
« on: September 11, 2013, 07:54:35 pm »
I like the new changes. :)

Can you please keep some running documentation on the 'ROM' hash method used for each platform (ie strip header for SNES and deinterleave, remove header for GEN). That should probably be included with program documentation so everybody knows exactly what constitutes a 'ROM' hash (as opposed to a file hash) for each platform. It would be good to have all these platform rules compiled for future use as well.

One other useful thing for use on this site would be to bold some of the information fields that have a place here such as anything applicable found in our 'Patching Information' drop down. That will aid people in knowing if their ROM has a header, is interleaved, is SMD or BIN, Byte Swapped etc.

Lastly, for PSX games, the identifying information is typically a  serial number (SLUS, SLPS etc.) rather than identification in a ROM database. Here is one such list. I haven't really been involved in the details to tell you what should be done here. Hopefully someone better versed in PSX can chime in on how to best do this.

Programming / Re: Getting Started on a VWF?
« on: September 08, 2013, 10:43:27 am »
So what I need to do is hijack the routine that basically loads 7E0604 and gets the Tilemap data, correct?  So would I have to drop how it gets the value from VRAM and make it read from ROM instead.  Then transfer that from ROM to RAM to VRAM?

What are you going to read from ROM? For a VWF, you're going to create dynamic tiles in RAM (since you no longer will have one letter per tile). You will be copying those tiles to VRAM and then altering the tilemap to now point to those tiles.

Programming / Re: Getting Started on a VWF?
« on: September 06, 2013, 07:48:23 pm »
210B/210C gets stored twice it seems.  Each resulting in '11' as the byte.

There is an $11 in $210b and $210C  is $00. If you look at the details on those registers, you'll see there is a nibble for each of the 4 background layers tile bases. That's why BG3 and 4 have a base of $0000 and BG 1 and 2 have $2000.

So would it be like Tile Number = 49 * 8 * 2 = 490 (Which is actually where 'I' is stored in VRAM)
That part is correct.

Does this apply to all background layers?

Yes. That whole paragraph is a fancy way of saying the tilemap will vary in the size it takes in VRAM depending on the tilemap size you use for the background. Toggle the last two bits of $2109 to see the tilemap effects on that layer. The background size will change from 1 to 4 maps to make up the entire layer.

Programming / Re: Getting Started on a VWF?
« on: September 05, 2013, 06:07:13 pm »
All that's setting the Tile Base to $0000 in VRAM and then the tilemap to $1000.  I think that's what I've seen anyway.

So it picks the letter '49' (I) from 7E0604.  It's 49 08 now and that gets used as the index for tilemap entry and placement on screen basically?

Yes, that's correct. Read the section 'Tile Maps and Character Maps' from Anomie's register doc. You'll see how to interpret the tile index/number from the two byte entry. That indexes into the tile base area to the tile with the 'I' on it.

Edit: Semi off topic in a way, but isn't Tilemap editing for a sprite basically it's Sprite Assembly?  So isn't this essentially just a background layer assembly/construction to put into other terms?

Not really. These tilemaps are for background layers. None of this applies to OAM sprites. They're very different and have their own format and tables (which also can be tinkered with in VSNES to learn).

Gaming Discussion / Re: The Weariness
« on: September 05, 2013, 06:00:35 pm »
Regarding your waning interest in games, all I can really say is, there are thousands and thousands of them out there. Try something different, or drop gaming for a while and focus on that music! Variety is where it's at -- too much of any one thing will always lead to burnout.

I concur! Aftr 20 some years of playing games, I continue to find additional games I never knew about both going backwards and forwards in time. There are far more than I could ever even try in my lifetime. Remember, gaming has been around for decades. There's all kinds of games out there. If you start really looking and don't limit yourself to single platforms, ages, or genre, you'll find countless new titles you never knew existed. Do you know how many good PC adventure games were made in the 80's/90's? A whole cornucopia! A trip to GoG.com will show you a treasure-trove of old stuff if you're run out of new stuff.

General Discussion / Re: Recommendations for building new PC
« on: September 04, 2013, 05:58:52 pm »
I have to disagree. Although I almost never play games I'd never want to go back to having the OS and programs on an HDD. Everything's just so much smoother. (It also makes less noise)

Agreed. The system boots, loads, saves, installs, and runs a good bit faster and smoother with an SSD. You only need a small one for the OS and program installs. All your music, videos, and data can go on a traditional hard drive (but with only 50GB needs, it's probably a non-issue). I would highly recommend an SSD if you can fit it in the budget.

Programming / Re: Algorithms for optimum dictionary compression
« on: September 04, 2013, 05:47:03 pm »
I'd suggest taking a look at Script Crunch for some ideas and testing.

Programming / Re: Getting Started on a VWF?
« on: September 04, 2013, 05:45:01 pm »
I'm not sure HOW it takes that value from VRAM and uses it to get the actual tile from VRAM.

That's exactly what the tilemap does. It indexes other tiles in VRAM and maps where to put them on the screen. That's a function of the hardware. In other words, the tilemap in VRAM references other tiles also in VRAM. There will be no game code that reads any map from VRAM and fetches tiles from VRAM. That's a hardware function (defined by the related hardware registers) acting on the tile map and tile data in VRAM at any given time.

Again, I recommend using VSNES to play around with the registers and VRAM hex data to understand how it works.

Programming / Re: Getting Started on a VWF?
« on: September 03, 2013, 07:01:30 pm »
Do you know what a tilemap is, it's format, and how it works on the SNES? I'm not sure you understand exactly what you're looking for sometimes. A tilemap entry is always 2 bytes per tile. So, your single byte text letter is going to turn into a 2-byte tilemap entry. It's a simple conversion here as the game uses $49 $08 as the entry for the tilemap. I highly suggest using VSNES to play around. It will tell you precisely where in VRAM the tilemap is for a given layer in any savestate with text on it. You can then edit the VRAM bytes of said tilemap to see what happens. If you understand how a screen is put together, this stuff is much simpler.

Your text is on layer 3. The tilemap is stored at effective VRAM location 0x1000. This DMA transfer handles transfer of a single 2-byte tilemap entry of 'I' from 7E:0604 to the specific address this tile entry goes at in the tilemap in VRAM. In this game, each tilemap entry gets transferred individually it seems.

I assume your actual text string has 0x49 only, right? If so, there's a small routine that turns that into 0x49 0x08 that gets stored at 7E:0604 for the tilemap entry. For VWF purposes, you're going to hijack that routine. You're no longer going to do that simple conversion anymore, and you won't be using the static font anymore that is stored in VRAM. You'll be building new dynamic tiles and make the tilemap entries point to those new tiles.

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 73