SNES ROM programming stuff

view all posts by Ekarderif

(user is banned)

2005-09-26 10:24:06 am

I dunno if you should change the graphics too much in case of lag and other problems it may cause.

Thread title:

Ekarderif:

registered on 2004-05-13 03:35:09 am.

Ekarderif

2005-09-26 04:08:00 pm

Since when did swapping sprites slow down a game?

RT-55J:

registered on 2004-11-03 09:20:11 am.

Location: Wild Side Arcade

view all posts by RT-55J

RT-55J

2005-09-26 05:05:38 pm

Armor Guardian

Quote from Ekarderif:

Since when did swapping sprites slow down a game?

It's been like that since Dark SA-X made his post.

Yoshi348:

registered on 2003-09-15 04:52:52 pm.

Gender: male

Location: My own little world

view all posts by Yoshi348

Yoshi348

2005-09-26 09:15:15 pm

PAGE BREAKER

Ready and willing.

Heh.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-09-26 11:13:05 pm

Actually, editing sprites doesn't slow down the game.

Sasuke_Kun:

is in the group Banned.

registered on 2005-04-12 03:37:31 am.

Location: Konoha Village

(user is banned)

2005-09-27 04:19:51 am

I meant that putting loads and loads of sprites in one area would cause lag. Like making boss sprites into more separate pieces to add extra detail would cause lag if there were too many sprites there at once.

Hey, don't look at me, I've never designed my own game before...

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-09-27 01:16:54 pm

Actually, usually the Bosses use a very tight space, and usually there can't be added any more tiles/sprites to their area.
A good exception is fake Kraid.

As you can see, there is a bunch of X: es.
Those are unused tiles, which can be made un-un-used by adding something to them.
But, since the X :es were never used, they aren't added to Fake Kraid's animation tiles in the actual game. So drawing new face expressions/movement tiles/other on the X: es would be complete waste of time, since they cannot be seen in the game at any way.
But since they are still in the memory of Fake Kraid, and the game thinks that the new tiles take more memory than the X: es, it may slow the game down depending how many X: es you edited.
Anyway, it would slow the game down only a few milliseconds..

RT-55J:

registered on 2004-11-03 09:20:11 am.

Location: Wild Side Arcade

view all posts by RT-55J

RT-55J

2005-09-27 04:44:11 pm

Armor Guardian

Actually, the 'X'es take up as much space in the RAM as an edited tile would.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-09-27 11:28:02 pm

They do?

Okay then... Embarassed

Sasuke_Kun:

is in the group Banned.

registered on 2005-04-12 03:37:31 am.

Location: Konoha Village

(user is banned)

2005-09-28 03:18:00 am

I think I've made my point...

sylux:

is in the group Banned.

registered on 2005-09-09 01:12:47 pm.

(user is banned)

2005-09-28 07:42:36 am

the snes has like 7 gfx modes and they all have limits of how many sprites or tiles they can render... the sprite layr i beleive is 128 sprites (i could be wrong maybe its the gba that has 128sprites) all sprites are made of 8x8 tiles and to make a "larger" sprite its usually consistant of multible 8x8 tiles... you cant realy create any slowdown by putting more sprites in the room... all that will happen is the game simply wont Render them.

Sasuke_Kun:

is in the group Banned.

registered on 2005-04-12 03:37:31 am.

Location: Konoha Village

(user is banned)

2005-09-28 02:50:39 pm

...and just had that point completely ridiculed in every way.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-09-29 11:39:28 am

Sylux just made me smile.

sylux:

is in the group Banned.

registered on 2005-09-09 01:12:47 pm.

view all posts by Kejardon

(user is banned)

2005-09-30 04:32:13 am

and since i can finally see thepicture you posted... those so called "X's" are just transparent parts of the picture... since the hack program doesnt recadize it they show up as X's(sue to the imcompletion of the hacking program) and also sprites arent stored like that on the rom theres stored as something like this

Code:

(this is stored in a pallete file):
1 = 482828
2 = 885038
3 = D87838
4 = D8F8A8
5 = D8F8F8
(its usually a HEX color but sometimes it can be RGB)

0 0 0 0 1 1 0 0
0 0 0 2 2 1 1 0
0 4 5 4 3 2 1 1
4 5 5 4 3 3 2 1
4 5 5 4 3 3 2 1
0 4 5 4 3 2 1 1
0 0 0 2 2 1 1 0
0 0 0 0 1 1 0 0

(im not toally shore how the pallete file is done weither its stored in the same file or its in a seperate one. there is also a command to tell it weither the mage is 8/16/24 bit)

which draws this :

(BTW if you zoom in on it dose anyone realise that the Power Beam from asmus looks like an 8-bit A-Corn?)

if you actually decompiled the rom into raw files you could hack it much easier... but i dont think there are any anymore. i havnt been able to find one

and also the sprites can be "enlarged" but smile(or any other hacker) cant do it. this also is something a decompiler can be used for. the "Hack" just edits things and cant create new stuff

and the tiles can be easily edited the sprites however usually have behavours which is why some tiles and sprites dont show up in a hack(notice all the 8x8 tiles with X's in them and nothing else) its because there not a standard sprite/tile.

(also i edited this about 6 or 7 times lol so if some of it dont make sense im sorry)

and since i can finally see thepicture you posted... those so called "X's" are just transparent parts of the picture... since the hack program doesnt recadize it they show up as X's(sue to the imcompletion of the hacking program) and also sprites arent stored like that on the rom theres stored as something like this

[code](this is stored in a pallete file):
1 = 482828
2 = 885038
3 = D87838
4 = D8F8A8
5 = D8F8F8
(its usually a HEX color but sometimes it can be RGB)

0 0 0 0 1 1 0 0
0 0 0 2 2 1 1 0
0 4 5 4 3 2 1 1
4 5 5 4 3 3 2 1
4 5 5 4 3 3 2 1
0 4 5 4 3 2 1 1
0 0 0 2 2 1 1 0
0 0 0 0 1 1 0 0[/code]

(im not toally shore how the pallete file is done weither its stored in the same file or its in a seperate one.  there is also a command to tell it weither the mage is 8/16/24 bit)

which draws this :

[img]http://img147.imageshack.us/img147/9306/pbshot0vo.gif[/img]

(BTW if you zoom in on it dose anyone realise that the Power Beam from asmus looks like an 8-bit A-Corn?)

if you actually decompiled the rom into raw files you could hack it much easier... but i dont think there are any anymore. i havnt been able to find one

and also the sprites can be "enlarged" but smile(or any other hacker) cant do it. this also is something a decompiler can be used for. the "Hack" just edits things and cant create new stuff

and the tiles can be easily edited the sprites however usually have behavours which is why some tiles and sprites dont show up in a hack(notice all the 8x8 tiles with X's in them and nothing else) its because there not a standard sprite/tile.

(also i edited this about 6 or 7 times lol so if some of it dont make sense im sorry)

Kejardon:

registered on 2004-12-07 07:21:36 pm.

Gender: male

Kejardon

2005-09-30 10:04:44 am

Embarrasing Fact: Power suit made by lowest bidder

Actually, those *are* X's.
Colors have 5 bits for red, green, and blue. Ergo there are 2^15 colors, and each unique color can be stored as a single byte.
The graphics are actually saved something like this:

Code:

0 0 0 0 1 1 0 0 = 0C
0 0 0 0 0 1 1 0 = 05
0 0 1 0 1 0 1 1 = 2B
0 1 1 0 1 1 0 1 = 6D
0 1 1 0 1 1 0 1 = 6D
0 0 1 0 1 0 1 1 = 2B
0 0 0 0 0 1 1 0 = 05
0 0 0 0 1 1 0 0 = 0C

0 0 0 0 0 0 0 0 = 00
0 0 0 1 1 0 0 0 = 18
0 0 0 0 1 1 0 0 = 0C
0 0 0 0 1 1 1 0 = 0E
0 0 0 0 1 1 1 0 = 0E
0 0 0 0 1 1 0 0 = 0C
0 0 0 1 1 0 0 0 = 18
0 0 0 0 0 0 0 0 = 00

0 0 0 0 0 0 0 0 = 00
0 0 0 0 0 0 0 0 = 00
0 1 1 1 0 0 0 0 = 70
1 1 1 1 0 0 0 0 = F0
1 1 1 1 0 0 0 0 = F0
0 1 1 1 0 0 0 0 = 70
0 0 0 0 0 0 0 0 = 00
0 0 0 0 0 0 0 0 = 00

Then on top of that, many graphics are compressed.

A decompiler will probably not be able to make any sense of graphics and music data stored in the game, since the game uses it's own routines to load and translate the music and graphic data from rom to ram.
It wouldn't be impossible to create such a program, but essentially what it would have to do would be to emulate the routines, not decompile them.

::edit:: The easiest way is generally to find where the graphics are yourself, then decompress them and reformat them to what Windows or something uses. This is what SMILE does already for tiles (enemies come from pre-loaded graphics). For other graphics, you'd need Lunar Compress to decompress them (if they're compressed), then an appropriate editor to edit them.

Actually, those *are* X's.
Colors have 5 bits for red, green, and blue. Ergo there are 2^15 colors, and each unique color can be stored as a single byte.
The graphics are actually saved something like this:
[code]
0 0 0 0 1 1 0 0 = 0C
0 0 0 0 0 1 1 0 = 05
0 0 1 0 1 0 1 1 = 2B
0 1 1 0 1 1 0 1 = 6D
0 1 1 0 1 1 0 1 = 6D
0 0 1 0 1 0 1 1 = 2B
0 0 0 0 0 1 1 0 = 05
0 0 0 0 1 1 0 0 = 0C

0 0 0 0 0 0 0 0 = 00
0 0 0 1 1 0 0 0 = 18
0 0 0 0 1 1 0 0 = 0C
0 0 0 0 1 1 1 0 = 0E
0 0 0 0 1 1 1 0 = 0E
0 0 0 0 1 1 0 0 = 0C
0 0 0 1 1 0 0 0 = 18
0 0 0 0 0 0 0 0 = 00

0 0 0 0 0 0 0 0 = 00
0 0 0 0 0 0 0 0 = 00
0 1 1 1 0 0 0 0 = 70
1 1 1 1 0 0 0 0 = F0
1 1 1 1 0 0 0 0 = F0
0 1 1 1 0 0 0 0 = 70
0 0 0 0 0 0 0 0 = 00
0 0 0 0 0 0 0 0 = 00
[/code]

Then on top of that, many graphics are compressed.

A decompiler will probably not be able to make any sense of graphics and music data stored in the game, since the game uses it's own routines to load and translate the music and graphic data from rom to ram.
It wouldn't be impossible to create such a program, but essentially what it would have to do would be to emulate the routines, not decompile them.

::edit:: The easiest way is generally to find where the graphics are yourself, then decompress them and reformat them to what Windows or something uses. This is what SMILE does already for tiles (enemies come from pre-loaded graphics). For other graphics, you'd need Lunar Compress to decompress them (if they're compressed), then an appropriate editor to edit them.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-09-30 02:08:21 pm

Sooo...
Nobody won?

sylux:

is in the group Banned.

registered on 2005-09-09 01:12:47 pm.

(user is banned)

2005-10-01 01:49:49 am

no there not stored like that thats how you "Hack" the .smc. decompressing it will leave you with the game files (i.e pictures and snes EXEcutables) look up on the net you should be able to find some decent tutorials on programming for the snes. i know there are compilers to make your own .smc files bbut i havnt been able to find a de-compiler.

the grafix are stored as a number reference and they DONT have spaces in them i only put it there cuz it looks easier to read that way. each number has a reference

i.e in the picture i displayed there were 5 colors each determininded by the pallete(im not sure how the pallete is stored tho). and 0 is transparent.

makes:

Heres how it works:

each pixel has a number i.e

Code:

0 0 0 0 1 1 0 0
0 0 0 2 2 1 1 0
0 4 5 4 3 2 1 1
4 5 5 4 3 3 2 1
4 5 5 4 3 3 2 1
0 4 5 4 3 2 1 1
0 0 0 2 2 1 1 0
0 0 0 0 1 1 0 0

and each number has a color (determined by a Pallete)

in this case the pallete would be something like

0 = ??, ??, ?? (Transparent)
1 = 72, 40, 40
2 = 136, 80, 56
3 = 216, 120, 56
4 = 216, 248, 168
5 = 216, 248, 248

i dont know if there stored as hex RGB or another way tho

the snes parses the numbers and refering the the data it renders it
(all sprites and tiles are 8x8 pixels no biger no smaller and this is one of the reasons Bosses and such cant be enlarged because the game engine has the boss fitted to (xxx ammount of 8x8 pixel tiles) making it bigger would require you to have the source code to the original Snes EXE and you would have to write collision detections and behavours)
and the game sets the layers (i.e mode 1 (BG) or tiles sprites etc.) and renders 1px dots to form the picture.

and for this reason compression is not required as there stored takign up pretty much no space at all.

the X's are the hack trying to render the 0's(most of the SM hacks are coded in VB or Delphi and they dont support codes like that and need to have substitutes) but as it edits the .smc it saves invalid numbers (again due to the lack of the programs completion and would probably have been fixed in a later version if it was still being continued). my guess is that they come out as X's because the program doesnt support the transparent pixels and the program makes X's instead

and what you said about the games having there own routines to load graffix is true but metroid is NINTENDO and the snes has its own function for rendering graffix. so i highly doubt nintendo would have deviated from it.

no there not stored like that thats how you "Hack" the .smc. decompressing it will leave you with the game files (i.e pictures and snes EXEcutables) look up on the net you should be able to find some decent tutorials on programming for the snes. i know there are compilers to make your own .smc files bbut i havnt been able to find a de-compiler.

the grafix are stored as a number reference and they DONT have spaces in them i only put it there cuz it looks easier to read that way. each number has a reference

i.e in the picture i displayed there were 5 colors each determininded by the pallete(im not sure how the pallete is stored tho). and 0 is transparent.

makes:

[img]http://img147.imageshack.us/img147/9306/pbshot0vo.gif[/img]

Heres how it works:

[img]http://img7.imageshack.us/img7/5561/pbshotexp0bc.gif[/img]

each pixel has a number i.e

[code]0 0 0 0 1 1 0 0
0 0 0 2 2 1 1 0
0 4 5 4 3 2 1 1
4 5 5 4 3 3 2 1
4 5 5 4 3 3 2 1
0 4 5 4 3 2 1 1
0 0 0 2 2 1 1 0
0 0 0 0 1 1 0 0[/code]

and each number has a color (determined by a Pallete)

in this case the pallete would be something like

0 = ??, ??, ?? (Transparent)
1 = 72, 40, 40
2 = 136, 80, 56
3 = 216, 120, 56
4 = 216, 248, 168
5 = 216, 248, 248

i dont know if there stored as hex RGB or another way tho

the snes parses the numbers and refering the the data it renders it
(all sprites and tiles are 8x8 pixels no biger no smaller and this is one of the reasons Bosses and such cant be enlarged because the game engine has the boss fitted to (xxx ammount of 8x8 pixel tiles) making it bigger would require you to have the source code to the original Snes EXE and you would have to write collision detections and behavours)
and the game sets the layers (i.e mode 1 (BG) or tiles sprites etc.) and renders 1px dots  to form the picture.

and for this reason compression is not required as there stored takign up pretty much no space at all.

the X's are the hack trying to render the 0's(most of the SM hacks are coded in VB or Delphi and they dont support codes like that and need to have substitutes) but as it edits the .smc it saves invalid numbers (again due to the lack of the programs completion and would probably have been fixed in a later version if it was still being continued). my guess is that they come out as X's because the program doesnt support the transparent pixels and the program makes X's instead

and what you said about the games having there own routines to load graffix is true but metroid is NINTENDO and the snes has its own function for rendering graffix. so i highly doubt nintendo would have deviated from it.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

2005-10-01 03:37:58 am

Sooo...
What's your point?

sylux:

is in the group Banned.

registered on 2005-09-09 01:12:47 pm.

view all posts by Kejardon

(user is banned)

2005-10-01 06:22:09 am

well maybe if you knew a little programming and werent stuck hacking a rom you would know what im talking about.

since you dont my point is that the X's are transparent pixels and my first point was that you cant greate game-slowdown simply by putting to many sprites in it ...

Kejardon:

registered on 2004-12-07 07:21:36 pm.

Gender: male

Kejardon

2005-10-01 10:43:16 am

Embarrasing Fact: Power suit made by lowest bidder

The game creates the graphics like that, yes, but the pixels get those numbers in rom from 'layers' of bytes, like what I wrote.
And as I said, RGB is stored as a single 15-bit color. (0rrr rrgg gggb bbbb). That's why the numbers you found are all multiples of 8 - that's the most color resolution the game has.

There ARE X's in the game. If there were 0's instead, you'd just see a bunch of black space. There's no reason why they wouldn't be able to draw anything the rom came up with.

Quote:

(most of the SM hacks are coded in VB or Delphi and they dont support codes like that and need to have substitutes)

This sentence makes little sense. I assume you mean that most of the programs that hack SM are coded in VB or Delphi (which is correct, SMILE is in VB and Ultima's editor was in Delphi).
It still has nothing to do with wht you're talking about, though.

SMILE is perfectly capable of reading the files properly. You can SEE x's in the original game if you use codes to enable scrolling to screens that use tiles with x's.

There is compression. I can vouch for that first hand. Whether it's necessary or not, there is compression. Not *everything* is compressed, but a lot is.

Quote:

the snes has its own function for rendering graffix.

The hardware, once the data is in the proper registers, will render the graphics the same way every time.
The software, which gets the data from the rom and feeds it into the registers, will be designed to work with whatever format / compression the graphics are in.
Different teams of programmers may use different standards for graphics - Nintendo is not composed of a single group of programmers. Standards also change over time as new techniques come about, and as new chips were put into the games for better graphics.

The disassembler I've been using as of late is one made by MathOnNapkins. It's still in progress, but it works well and does what I want it to do for individual routines (though its error checking bugs me sometimes)
As far as I know, there's no full 'decompiler' for the SNES. That's why people are mapping out routines, graphics, and music themselves instead of sticking the .scm file into a decompiler and saving themselves a ton of work.

One last thing. Snes EXEcutables? What do you think a .smc file is?
From the knowledge you've 'shown' about the SNES, I'm more than willing to bet that I know more about programming on the SNES than you do. Heh... I'm wondering what you're calling a 'compiler' for the SNES. Generally you use assemblers since you're programming in assembly, are you talking about programming in C or something and compiling it for the SNES?

The game creates the graphics like that, yes, but the pixels get those numbers in rom from 'layers' of bytes, like what I wrote.
And as I said, RGB is stored as a single 15-bit color. (0rrr rrgg  gggb bbbb). That's why the numbers you found are all multiples of 8 - that's the most color resolution the game has.

There ARE X's in the game. If there were 0's instead, you'd just see a bunch of black space. There's no reason why they wouldn't be able to draw anything the rom came up with.

[quote](most of the SM hacks are coded in VB or Delphi and they dont support codes like that and need to have substitutes)[/quote]

This sentence makes little sense. I assume you mean that most of the programs that hack SM are coded in VB or Delphi (which is correct, SMILE is in VB and Ultima's editor was in Delphi).
It still has nothing to do with wht you're talking about, though.

SMILE is perfectly capable of reading the files properly. You can SEE x's in the original game if you use codes to enable scrolling to screens that use tiles with x's.

There is compression. I can vouch for that first hand. Whether it's necessary or not, there is compression. Not *everything* is compressed, but a lot is.

[quote]the snes has its own function for rendering graffix.[/quote]

The hardware, once the data is in the proper registers, will render the graphics the same way every time.
The software, which gets the data from the rom and feeds it into the registers, will be designed to work with whatever format / compression the graphics are in.
Different teams of programmers may use different standards for graphics - Nintendo is not composed of a single group of programmers. Standards also change over time as new techniques come about, and as new chips were put into the games for better graphics.

The disassembler I've been using as of late is one made by MathOnNapkins. It's still in progress, but it works well and does what I want it to do for individual routines (though its error checking bugs me sometimes)
As far as I know, there's no full 'decompiler' for the SNES. That's why people are mapping out routines, graphics, and music themselves instead of sticking the .scm file into a decompiler and saving themselves a ton of work.

One last thing. Snes EXEcutables? What do you think a .smc file is?
From the knowledge you've 'shown' about the SNES, I'm more than willing to bet that I know more about programming on the SNES than you do. Heh... I'm wondering what you're calling a 'compiler' for the SNES. Generally you use assemblers since you're programming in assembly, are you talking about programming in C or something and compiling it for the SNES?

RT-55J:

registered on 2004-11-03 09:20:11 am.

Location: Wild Side Arcade

view all posts by RT-55J

RT-55J

2005-10-01 01:19:27 pm

Armor Guardian

Sylux has been officially owned be Kejardon.

sylux:

is in the group Banned.

registered on 2005-09-09 01:12:47 pm.

(user is banned)

2005-10-02 05:36:02 am

no idiot... vb and delphi cant render transparent picels without api and it isnt supported in any known SM hacks...

No compression is used in snes games the only graffix that have "compression" are the animated tiles or tiles that have special propertys. and if you compare how much IS compressed and how much is NOT id think you would see it the other way around.

the SNES has an function for rendering the graffix a simple set mode and set gfx simple enuf? i said nintendo wouldnt deviate from the snes's default graffix rendering function. its there for a reason nintendo made the snes and metroid and i doubt they would make a custom function to render the graffix another way.

.SMC is what an ISO is to a pc... same as what .NDS is to a nintendo DS. you can call it a executable if you want(since the snes dose boot that file) but inside you will find data files. i.e a Default .EXE name(im not sure what the extention for the snes is). for xbox it is default.xbe

and yes i am talking about C there are few people that can create full fledged games in ASM. most people use C and ASM but hardly ever will you see a game completly coded in ASM

EDIT: there are decompilers for the NDS .NDS files so i would assume the same of the snes. i am yet to find one tho(atleast one with fully working functions)

no idiot... vb and delphi cant render transparent picels without api and it isnt supported in any known SM hacks...

No compression is used in snes games the only graffix that have "compression" are the animated tiles or tiles that have special propertys. and if you compare how much IS compressed and how much is NOT id think you would see it the other way around.

the SNES has an function for rendering the graffix a simple set mode and set gfx simple enuf? i said nintendo wouldnt deviate from the snes's default graffix rendering function. its there for a reason nintendo made the snes and metroid and i doubt they would make a custom function to render the graffix another way.

.SMC is what an ISO is to a pc... same as what .NDS is to a nintendo DS. you can call it a executable if you want(since the snes dose boot that file) but inside you will find data files. i.e a Default .EXE name(im not sure what the extention for the snes is). for xbox it is default.xbe

and yes i am talking about C there are few people that can create full fledged games in ASM. most people use C and ASM but hardly ever will you see a game completly coded in ASM

EDIT: there are decompilers for the NDS .NDS files so i would assume the same of the snes. i am yet to find one tho(atleast one with fully working functions)

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland

view all posts by Kejardon

2005-10-02 06:05:15 am

Kewl.
If I'll practice enough, I could make a speed run of this!

Kejardon:

registered on 2004-12-07 07:21:36 pm.

Gender: male

Kejardon

2005-10-02 12:26:12 pm

Embarrasing Fact: Power suit made by lowest bidder

Hmm. Apparently, I'm mistaken about those x's, I just checked and it was blank in-game. I was almost sure they were there, though.

"vb and delphi cant render transparent picels without api and it isnt supported in any known SM hacks... "
What is this 'it' you're referring to? >_> Transparent pixels? Layer 3 liquid / fog editing?
And please, when you're referring to the programs, say programs. When you're referring to the edited games, say hacks. I'm fairly sure Super Metroid wasn't programmed in either visual basic nor delphi.

If there's no compression, why do you need to use something like Lunar Compress to decompress many of the graphics in Super Metroid? >_>
Certainly, not all of it, or not even most of it is compressed, but there is compression.

I hate to repeat myself, but the hardware will render the graphics a set way. The software won't feed it to the hardware in a set way, though.
There are standards that are commonly used, the one I'm referring to (and I slightly messed up in my post) is 3bpp. The first two layers are supposed to be intermeshed (I have them seperate), and the third layer is just after the first two.

I looked around for a while, and eventually found http://www.avocetsystems.com/company/search/search.php?chip=65816.
A bit more searching gave http://www.cc65.org/. Those were the only ones I could find.

Most information for programming on the SNES dealt with assembly, and what little that wasn't mainly used higher level programming languages for making tools to edit graphics / sound, not for compiling code from those langauges to 65816 binary.
I think you're in the minority if you program on the SNES in a higher level language. :P

Not sure about this part... but seeing as it's common to use a lot of assembly while programming for the SNES, wouldn't that make it harder to decompile it?
I've never tried to decompile something before, or even looked at other people decompiling files before. I generally assumed it was easiest just to work in assembly, unless the programmers used a very high level language to produce it.

Hmm. Apparently, I'm mistaken about those x's, I just checked and it was blank in-game. I was almost sure they were there, though.

"vb and delphi cant render transparent picels without api and it isnt supported in any known SM hacks... "
What is this 'it' you're referring to? >_> Transparent pixels? Layer 3 liquid / fog editing?
And please, when you're referring to the programs, say programs. When you're referring to the edited games, say hacks. I'm fairly sure Super Metroid wasn't programmed in either visual basic nor delphi.

If there's no compression, why do you need to use something like Lunar Compress to decompress many of the graphics in Super Metroid? >_>
Certainly, not all of it, or not even most of it is compressed, but there is compression.

I hate to repeat myself, but the hardware will render the graphics a set way. The software won't feed it to the hardware in a set way, though.
There are standards that are commonly used, the one I'm referring to (and I slightly messed up in my post) is 3bpp. The first two layers are supposed to be intermeshed (I have them seperate), and the third layer is just after the first two.

I looked around for a while, and eventually found http://www.avocetsystems.com/company/search/search.php?chip=65816.
A bit more searching gave http://www.cc65.org/. Those were the only ones I could find.

Most information for programming on the SNES dealt with assembly, and what little that wasn't mainly used higher level programming languages for making tools to edit graphics / sound, not for compiling code from those langauges to 65816 binary.
I think you're in the minority if you program on the SNES in a higher level language. :P

Not sure about this part... but seeing as it's common to use a lot of assembly while programming for the SNES, wouldn't that make it harder to decompile it?
I've never tried to decompile something before, or even looked at other people decompiling files before. I generally assumed it was easiest just to work in assembly, unless the programmers used a very high level language to produce it.

Raccoon Sam:

registered on 2005-07-10 12:01:04 pm.

Location: Finland