 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by TapamN |
| User | Post | ||
|
TapamN Newcomer Level: 1 Posts: 1/1 EXP: 4 For next: 7 Since: 10-13-05 Since last post: 20 days Last activity: 6 days |
| ||
| Writing a level editor? Hm. I'm working on a level editor for Sonic 1, writen in VB6. I'm cheating because it only works on Sonic 1 when it's uncompressed, disassembled, and split into seperate files. The ugly things like compression and space restrictions are handled when it's compiled. When writing your own level editor, first, figure out formats and compression. (I only had to figure out formats.) Find any existing docs and start coding the editor to display the most basic parts. You should start with graphics because, well, you need something to see how the editor is loading data. It's a good idea to read pallete and graphics from the ROM for two main reasons: A more accurate preview (incase some smart aleck thinks it's a good idea to edit the pictures and colors) and it makes for easier design and coding. How? If you load the tiles the same way the game does, you can use the same numbers to reference the graphics. I can't think of a better what to expain it, so let me give you an example. In Sonic 1, there are mappings made out of a 2*2 block of tiles. The data for the mappings use numbers that line up with how they are loaded into RAM. Tile 24 in the ROM uses tile 24 in RAM. If you load the graphics from the ROM properly, it's all lined up for you. If you read the graphics out of a BMP, you need to line it up ahead of time or have the program compensate. Once you have graphics, you can start on the actual level data. Start out with just figuring out how to read the data and display it with the graphics you loaded. If the documentation you have is wrong, well... you can see how it's wrong. The docs I used were out of date and had incorrect explanations for tile flipping. This was easy to figure out because... the graphics were flipped wrong when I displayed them.  If it helps, this is the order I did stuff on my editor. 1. Research 2. Load and display palletes 3. Load and display graphics with pallete 4. Load and display basic tile mappings with graphics 5. Load and display compound tile mappings with basic tile mappings 6. Load and display level with compound tile mappings 7. Edit level Mega-Dog: My Sonic 1 level editor, also writen in VB6, does, at worst, .55 seconds on my 667 mhz P3 when drawing 4096 tiles (64*64 8*8 tiles / Total: 512*512 pixels). My budget 1.3 ghz Celeron M laptop does the same thing in .0078 seconds. I've yet to optimize. My level editor doesn't even read level data from RAM, and it reads it byte by byte from disk. (Of course, disk cache helps.) How are you drawing the screen? I use BitBlt and StretchBlt (for mirroring and flipping). ... I think that's mostly it... Oh, modulus is your friend when making an editor. |
| Acmlm's Board - I2 Archive - - Posts by TapamN |
