You are not logged in.
I have finished the final changes following my BETA (including some nice new additions/changes that were suggested!) my romhack is pretty much complete.
I have two things remaining. The typing bug outlined elsewhere, and the insertion of my new sprites. I have 4 that need to be inserted into my rom. Miksy advised that they can be compressed and inserted into the game using AGIXP, although I could have an issue running the program and - if that's the case - I should ask you fine folks for your help inserting them for me.
So, can anybody here insert these sprites in for me please? I only have four sprites that need to be inserted, and they are already made ready to be put in.
As this is pretty much the finishing touch, I can pay for your help if you like. After many, many months of solid work on this I am looking forward to getting everything finalised.
Bumped because I still need help and this is the last thing I need to do to finish. AGIXP doesn't work on my system so my only option is to seek help elsewhere.
What error are you getting when you say it doesn't work on your system?
#1 Mightyena fan.
System Error &H8007007E (-2147024770)
Well apparently it still asks for FM20.DLL even though I went in elevated command prompt to run regsvr32 on it. It says component registered properly but then the program still complains that it's missing. :/ Otherwise I'd try.
#1 Mightyena fan.
Yeah, it seems really buggy. Hopefully it works for someone though.
Thanks anyway for trying :/
I figured you could also fork disassembly in github and edit your forked version there to add those new sprites in the game. Then you can compile the disassembly and look for the inserted (and compressed) image data in the compiled rom (via pointer table of the battle sprites). There you could pick up the data and copy paste it to your hacked rom.
AgiXp doesn't work on my pc either so I can't do it straight for you either. It should work in another pc in my hometown where my mom lives though (which has Windows XP in it). I have always used that one for inserting sprites.
Don't we have any other kind of a program which you could provide some image and it would show the byte code (with the same compression technique used in GSC) which you could just copy paste into the rom? I haven't heard of one but this kind of a tool would be useful (and not even difficult to make).
Last edited by Miksy91 (2016-06-20 15:19:50)
There is one. http://fusoya.eludevisibility.org/lc/index.html
AGIXP is known to occasionally write the pic size at random addresses. Using Lunar Compress and manually changing the pic size if necessary makes the most sense here.
What Lunar Compress doesn't do is turn your png/bmp/whatever graphics into planar 2bpp.
I would only use the disassembly's compressor as a last resort. But if you do, it's the same concept as Lunar Compress: you can just grab the compressed file instead of looking for it in the rom. And it will do the png->2bpp part for you. Instead of compiling the rom, you would just do:
python gfx.py 2bpp my_image.png # this creates my_image.2bpp python gfx.py lz my_image.2bpp
Then my_image.2bpp.lz is your compressed file.
Last edited by comet (2016-06-21 04:56:14)
Presumably I would need the file in 2bpp, sure the lunar compress approach would be pointless? Or do you mean use LC to change the size and then finish off with disassembly's compressor?
I'm still a little lost. I think the simplest approach may be to learn how disassembly works and do it that way. Presumably I can just copy the hex data from the rom it creates and put into mine, and that would work fine? I have tried pulling apart my hack in disassembly and it just doesn't work. I think I have made too many changes.
You could try using Lunar Compress as well. It's documented pretty badly, but by taking a look at its Readme, the creator states that documentation on compression formats is found inside DLLCode/LunarDLL.H and DLLCode/LunarDLL.DEF. These are actually C-program files and in ".H" file you can find these:
unsigned int Format - compression format (see table below). unsigned int Format2 - must be zero unless otherwise stated. ... LC_LZ3 Pokemon Gold & A fairly enhanced form of LZ2. Implemented Silver (GB) [G] as documented by Necrosaro.
and in .DEF file this:
#define LC_LZ3 2
In other words, the "code" for using compression format LC_LZ3 is number '2'. If you now open recomp.exe, it tells you to write "recomp.exe [input image file] [output image file (can be new file)] [Offset in output file to start saving to (= set to '0' to write to beginning of output file)] [Format (which happens to be '2')] [Format2 (which happens to be '0' as seen in .DLL file)]. In other words, write the following with command prompt by having the input image file in the same directory with recomp.exe:
recomp.exe [input image file name] [output file name] 0 2 0
and try copy pasting the contents of the output file to your hack and see if the sprite works correctly.
Last edited by Miksy91 (2016-06-21 17:44:52)
Am I missing something with disassembly? The disassembly option sounds simpler, but not entirely sure how to actually use it. I have installed it all using Cygwin and everything is on there..... but how to I edit stuff? Do you edit those through a separate program and then replace the files, and make the rom from there? It seems to be full of .LZ and .PAL files.
I looked at the PokeRed guide (http://pokemonhackersonline.com/showthr … or-Dummies) , and it says you can edit those via paint since they are .png files. I've tried looking for a crystal guide but found nothing. Any guidance?
For Crystal, the disassembly doesn't include PNGs directly. The .2bpp.lz are what you have and you can convert these to .2bpp then to .png with gfx.py. comet has explained this above already (the opposite process, granted, but still. :p)
python gfx.py unlz your_sprite.2bpp.lz python gfx.py png your_sprite.2bpp
Decompresses then converts to png, then you can convert back to 2bpp and recompress with what comet said above.
The resulting .png is some kind of scrambled sprite where all the tiles are scrambled. You'll have to figure out which tiles are which and edit them accordingly.
I'm still not sure how to edit this properly, because I converted a sprite to png, sorted out the tiles I needed to edit on the side, and put them back in place before resizing the picture back to its original size, and I converted it back to .2bpp + compressed back to .2bpp.lz, and replaced the original one with my edited one, and after compiling, no changes had actually happened in the game. Not sure if I was doing something wrong, because the .2bpp.lz and the palette file are the only two files I can find in the disassembly for this sprite. I don't think I need to touch the palette, so the only thing left is the compressed picture, which I edited, but nothing changed after replacing with my edited sprite, so...
Maybe I was extra dumb and accidentally ran an unmodified rom instead of the newly compiled one :/ I'm pretty sure I ran the rom I had just compiled though. But this makes me feel like I need to try again now.
If you're looking to edit in the disassembly and compile though, be aware that if the resulting edits are too much bigger than the originals, it can cause problems ("C:\cygwin\usr\local\bin\rgbasm.exe: Section 'Pics 8' is too big (old size 15855 + 576 > 16384)")
As far as I know pokecrystal isn't as advanced as pokered, so a lot of rom addresses and pointers are hardcoded. You'd have to manually edit those if your resulting edits were bigger than the originals to a certain extent.
Last edited by Ammako (2016-06-29 15:06:11)
#1 Mightyena fan.
Yeah, I looked at the github version and there only seemed to be the two files you mentioned. Hopefully someone can clarify this a bit more. In the meantime, I'll try to amend the tile as per your suggestion.
I thought it'd be simpler to be honest. Especially as the png files in the pokered disassembly aren't jumbled, which makes things a lot easier...
Thanks for your input.
Yeah, pokecrystal just isn't as advanced as pokered for now, so you'll have to make do with that. Like I said, to get .pngs you'll have to convert from .2bpp.lz, and what you get is a bit more difficult to work with.
Also yeah I'm really not sure what I was doing wrong the first time, because now that I've tried again it works just fine.
Last edited by Ammako (2016-06-29 15:18:35)
#1 Mightyena fan.
Well that's good that your method works. I'll divide my new pngs into 20 squares or whatever and just rearrange them. It'll be like those damn Unown puzzles, except in reverse!
Hopefully it shouldn't be too bad. I think I'm just gonna change the execs and Mewtwo. Giovanni is unimportant, anyway.
Well, I followed the advice above and inserted one of the three sprites I needed into my rom. After loading up my rom and continuing the test run, one of my pokemon messed up. Seems like this didn't work.
guess I'm back to square one :/
Did you have an image of valid size to begin with before running gfx.py to compress it? Valid sizes are 40x40, 48x48 and 56x56 pixels I think. After you compress the image (and copy paste that data into your rom), you also need to possibly edit the specifics of the pokemon to make the game know, which was size the uncompressed image.
Last edited by Miksy91 (2016-06-30 21:06:02)
It's a trainer, not a pokemon (although it affected a pokemon, for some reason :/)
The size was 80x80 so probably too big. Although I don't understand how a trainer 2/3 down the list of trainer can overwrite pokemon sprites, since it's not that much bigger. I'll resize it and try again tomorrow. I assume 56x56 will be ok for trainers as well as pokes?
You can't tell the game, what was the size of the uncompressed image you have for a trainer (unlike for a pokemon for which it can be 40x40, 48x48 or 56x56). Thus all of them have to be of same size (as uncompressed images).
I took a look at my DE folder and the front sprites of trainers I have there are 56x56 pixels. However, backsprite of player is of size 48x48. By the looks of that image you uploaded, you probably wanted to replace the backsprite of player? Try 48x48 pixel sprite for that.
Also, compressing 80x80 sprite can actually take quite a lot of room which can lead into errors unless you really had lots of room for the sprite you inserted. So it's really no wonder if something got broken when you inserted that in the game. But even more likely errors come from the uncompressing part when the game is run. The CPU probably kept uncompressing the whole image data into ram, and didn't stop in the middle way of the process. That lead into memory faults and so on (which may explain the stuff you see on screen in that image you uploaded).
Last edited by Miksy91 (2016-07-01 15:56:49)
Nope, wasn't a backsprite. I was altering the trainer sprite for the rocket exec. I resized and tried again. Didn't work. After going through the rocket HQ, it seems as if nothing else was affected this time (judging by a very small sample). However, the trainer sprite change proved somewhat.... unsuccessful.
I followed the instructions to the letter, this time with the resized sprite. After I used Hex Workshop to compare the original and the one with the updated sprite. I opened my rom and changed the altered bytes accordingly. This is the result:
I may have to resort to plan B and pay someone else to do this one small thing. I just can't do it. Everything else seems perfect so far (from what I've tested). Just the sprites left :/ I have zero idea what the heck I'm doing wrong!
I don't think I'll bother installing python to my hacking pc (which has windows os). I do have that in another pc though I use at work, but don't want to install rom hacking stuff there either (so I could test this out myself)..
But you know what - I may visit my hometown next weekend. If I go there, I can try to get AgiXp running on a pc we've got there and if I do, insert a couple of sprites for you. Post something here on Saturday for instance and if I'm around there, I'll probably see your message here and can try it out. You could also email those sprites me so I could give it a try.
Thought I'd tag in here. First of all, I am looking at the alternative options to agiXP in this thread because agiXP just wasn't working on my PC. I have all the .dll and everything, but it will either freeze up, stop working (I get the tedious: AgiXP has stopped working prompt where you can only hit cancel) or the sprite will be a jumbled mess. I use windows 8 with compatibility mode btw.
but I tried the above and I extracted cyndaquils sprite. I see both a normal sprite and a jumbled mess. When I edited the normal sprite it showed up, and when I deleted the mess it just made it so cyndaquil was flashing in the pokemon status screen (His animations were gone).
I have a few questions.
I'm looking to replace pretty much all pokemon sprites with sprites of my own. I don't mind using the same sizes, but I would like to edit the palette of some of these pokemon. It seems it's a .pal file but none of my .pal editors (paint shop pro / pEdit) can open it. Is there a program that can?
and also, is there a way to disable animations in crystal? Can I do that in the assembly if I have to?
Are all pokemon going to be a normal sprite with a jumbled mess attatched to it or are some going to be exclusively jumbled?
thanks in advance!
.pal files are plain text files. For example, Cyndaquil's normal.pal file contains this:
RGB 31, 27, 00 RGB 31, 07, 05
The color channels range from 0 to 31.
One way to disable animations is to, for each Pokémon, edit its anim1.asm and anim2.asm files to just contain "endanim" and erase the contents of its bitmask.asm and frames.asm files. (All of these, along with normal.pal and shiny.pal, are in pokecrystal/gfx/pics/name.)
thanks for the reply. I'll just try that for the animations later.
I'm quite surprised that the palette file is just a text file.. wouldn't have expected.
But as far as I know the pokemon sprites use 4 colors.. what happened to the other 2? I only see the 2 colors you mentioned. if I look at cyndaquil's png it uses 4 colors for sure.