Sonic and Sega Retro Message Board: Dr. Kylstein - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

Member: Members
Active Posts:
85 (0.02 per day)
Most Active In:
Engineering & Reverse Engineering (58 posts)
05-June 08
Profile Views:
Last Active:
User is offline Yesterday, 05:40 PM

My Information

Age Unknown
Birthday Unknown
Not Telling Not Telling

Contact Information


Previous Fields

National Flag:

Posts I've Made

  1. In Topic: Help request: C-Programmer to add new function to WLA DX

    13 December 2013 - 06:46 PM

    Perhaps 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.
  2. In Topic: CSS: can I make nested list items justified with outer ones

    29 April 2013 - 02:13 PM

    You 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.)
  3. In Topic: Exploring Sonic Championship

    25 October 2012 - 10:22 PM

    View PostTiberious, on 24 October 2012 - 10:26 PM, said:

    Things to note:

    This game uses a strange interleaving pattern, where if the first 16 bytes of the 'whole' are:


    00 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:


    00 01 04 05 08 09 0C 0D

    and the .16 file will fill it out with its first 8 bytes being:


    02 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. )
  4. In Topic: Need to know how to make a tile editor / graphics editor

    14 September 2012 - 05:49 PM

    View PostElektro-Omega, on 14 September 2012 - 03:14 AM, said:

    Thank 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.

    View PostElektro-Omega, on 14 September 2012 - 03:14 AM, said:

    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.
  5. In Topic: Need to know how to make a tile editor / graphics editor

    12 September 2012 - 05:29 PM

    Glad to be of help.

    View PostElektro-Omega, on 12 September 2012 - 03:19 PM, said:

    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.