- Member: Members
- Active Posts:
- 85 (0.03 per day)
- Most Active In:
- Engineering & Reverse Engineering (58 posts)
- 05-June 08
- Profile Views:
- Last Active:
- Today, 06:55 PM
- Age Unknown
- Birthday Unknown
- Not Telling
- National Flag:
Posts I've Made
13 December 2013 - 06:46 PMPerhaps a pre-processor is in order? I remember reading about somebody piping their assembly through gpp (GNU C PreProcessor) to handle a problem like this. Or you might have an easier time finding a Python [or Perl, or whatever] programmer to make a custom pre-processor than a C programmer willing to create/hack an assembler.
29 April 2013 - 02:13 PMYou aren't using "em"s? It may not be exact for all fonts, but you should be able to get close and have it work at any size of a given font. (pixel positioning is evil.)
25 October 2012 - 10:22 PMThings to note:
This game uses a strange interleaving pattern, where if the first 16 bytes of the 'whole' are:
Quote00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
then the .15 file will have its first 8 bytes as:
Quote00 01 04 05 08 09 0C 0D
and the .16 file will fill it out with its first 8 bytes being:
Quote02 03 06 07 0A 0B 0E 0F
Pointers are backwards. For example, the first high score character name entry ('SONIC .') is at 097D84. In order to search for the pointer to it, you would search for: 84 7D 09 00.
If anyone else learns anything, post it up here. My hope is this initial set of finds turns into a concerted effort to bend this title to our will.
That interleaving looks like 16-bit ROM chips being used in a 32bit system. The pointers are probably little-endian, but my brief look into the i960 hasn't turned up anything about it. (I hope I'm not being a Captain Obvious here. )
14 September 2012 - 05:49 PMThank you for your help Dr. Kylstein, just another quick question. If I wanted to go the other way and allow users to load in a bitmap which would overwrite the default tileset would I simply load the file, strip the unnecessary information, perform the necessary transformations to the data (endian shifts and parsing) and then overwrite the default tile values?
Once you have a Surface with the new tiles stacked top to bottom, everything proceeds logically in reverse.
Quick Edit: Would this entire process be made incredibly harder with the exclusion of pygame. I cannot seem to make a fairy good gui for it and I am more accustomed to working with Tkinter. If the process becomes very longwinded and difficult without it, I will stick with pygame, I was just hoping to create a kind of native button feel to the application.
I haven't used Tkinter before, but it looks like the Python Imaging Library has integration for it. I can't help much with either of those, but it should be possible to do things in a similar way in PIL. Worst case, you may be able to pass the contents of a pygame Surface into PIL as a string.
Edit: I just want to note that I've always used Qt (with Pyside) for GUIs, and it can do everything. It may be much more complicated than Tkinter though.
12 September 2012 - 05:29 PMGlad to be of help.
I am still unsure how to actually sequentially load the tiles, do you mean literally load the entire start of the offset of the graphics to the end of the offset of the graphics into a single surface and then merely take select data out from the surface, or did you mean the data for each tile into a surface?
I think it is less overhead to have all the tiles in one Surface, and computing rectangles for blitting is trivial.
If I recall, the Megadrive/Genesis VDP tile format is one nybble per pixel, specifying the pixels from left to right, top to bottom for each tile in sequence. Given that, I'd load the byte-expanded pixels into an 8 by 8*number_of_tiles Surface. fromstring() will give a column of tiles automatically, but even plotting pixels this way is easier since you can ignore tile boundaries when you initially load the data. Then index*8 is the top of the Rect of any given tile index.