Points of Required Attention™
Smaghetti, a new Super Mario Advance 4 editor, is currently in development! Check out the thread HERE!

Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,312,610
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 03-28-24 09:50 AM
Guest: Register | Login

0 users currently in ROM Hacking | 4 guests | 2 bots

Main - ROM Hacking - Why do homebrewers write faster code than professionals? New thread | New reply


Aaendi
Posted on 03-17-10 03:30 AM Link | Quote | ID: 128494


Red Koopa
Level: 27

Posts: 56/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
I've read asm code from published games, and compared it to homebrew asm code from various people and I notice this a lot. I've even seen noobs write faster code than what I usually find in released games.

For example, if you ask a asm noob to move a sprite across the screen, you'd see something like this:

lda x_coordinate
inc a
sta x_coordinate

If you ask a homebrewer with a little more expirience, they might say:

inc x_coordinate

But if you ask a professional programmer working at Konami or Capcom, to make a sprite move across the screen, they make a long, confusing overcomplicated code that goes on and on. So long, you can't even figure out just exactly how does the code end up moving the sprite accross the screen.

elbobelo
Posted on 03-17-10 04:13 AM (rev. 2 of 03-17-10 05:21 PM) Link | Quote | ID: 128495


Red Koopa
Level: 27

Posts: 77/124
EXP: 107572
Next: 8587

Since: 08-16-07

Last post: 2139 days
Last view: 581 days
lda x_coordinate
inc a
sta x_coordinate

I found some situations where this way works and the other way doesn't. This way sets a flag once a => ff and that allows you to add the flag to another value with

lda x_coordinate
adc $00
sta x_coordinate

for the purpose of tracking that sprite over to the next ffxff screen in the x/y table.

If you only "inc x_coordinate" then that flag won't be set and the sprite will get lost if you are scrolling.

Just something I noticed.

KP9000
Posted on 03-17-10 04:35 AM Link | Quote | ID: 128496


Boomboom

Level: 90

Posts: 1238/1975
EXP: 6937266
Next: 251343

Since: 02-19-07

Last post: 3551 days
Last view: 3175 days


It's all a matter of a point-of-view. A paid programmer is someone that looks at his work as his job. He doesn't really care what kind of work he's doing, as long as it gets done. His incentive is a paycheck. A homebrewer on the other hand has an appreciation for the code and has a desire to purely create; with little to no ulterior motives. His incentive is a piece of material he has made himself, much like a painter or sculptor. These types of people often do things by themselves and often knows his resources and knows mistakes can be costly. He then becomes as best as he can be at his task.

____________________

messiaen
Posted on 03-17-10 05:40 AM Link | Quote | ID: 128500


Cheep-cheep
Level: 32

Posts: 169/193
EXP: 203940
Next: 2502

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4414 days
Last view: 4742 days
A homebrew developer can afford doing all kind of opmitizations for speed since most likely he is the only one ever touching the code. A paid programmer works on much more pressure and has to make sure his code is actually readable for him and for others otherwise it will be too time consuming to maintain it. Also, sometimes wasting an opcode or two to make sure the right value is on the right register may cost less than doing debugging later on just to discover another part of the program you just changed has broken something else.

Also, usually commercial projects are more complex, and as time goes by and release data gets nearer they may tend to get patchy.

Just my two cents, from an amateur programmer.

Aaendi
Posted on 03-17-10 03:02 PM Link | Quote | ID: 128513


Red Koopa
Level: 27

Posts: 57/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
Being a few cycles off never bothered me. It only bothers me when programmers is off by a factor of 10 or more that it starts to give me headaches.

Take for example Gradius 3, halfway through level 1, a fire dragon (who is made out of 10 sprites) comes out of the lava, and the game lags.

I've played around with multijointed sprites before, and it never caused the system to lag when I do it. Yes, WITH collsion applied.

MathOnNapkins
Posted on 03-17-10 03:56 PM Link | Quote | ID: 128517


Super Koopa
Level: 62

Posts: 756/842
EXP: 1931031
Next: 53655

Since: 02-19-07
From: durff

Last post: 4459 days
Last view: 3982 days
I think this is how it works. Programmers that make games first have to make something that works. Then they might have to add more shit to it per design requests, etc. Then I suppose they have to do some alpha testing and see how it all works together, b/c these games were all coded by more than one programmer. If it slows down too much to become unplayable, they have to optimize a bit. But I doubt they optimized as much as a rom hacker or homebrewer like us would. They probably get it as good as it has to be to be playable. It's actually not a good idea to optimize code first. Better to write it well with *good* design and then optimize after the fact (which could sully your design a bit).

Also consider than when you work with other people's code, you sometimes have to make concessions for their perhaps "suboptimal" coding mechanisms.

And some of those guys probably didn't know much at all about optimizing. When you can code with fancy macros, it makes coding easier but the inefficiency can often build up.

____________________
Zelda Hacking Forum
hobbies: delectatio morosa

Aaendi
Posted on 03-17-10 06:31 PM Link | Quote | ID: 128519


Red Koopa
Level: 27

Posts: 58/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
I guess when one guy tries to finish off someone elses code, crap happens.

Some good news, as of late I've got my platformer engine working, and I haven't ran into trouble with lagging yet.

I don't find macros to be that all bad. I use a lot of them in my platformer engine. They're much faster than subroutines, and I can still find optimization tricks around them.

such as:

%move(#$40,$0100)
%move(#$40,$0200)

being written as:

%move(#$40,$0100)
sta $0200

blackhole89
Posted on 03-18-10 12:47 AM Link | Quote | ID: 128527


The Guardian
Moloch whose eyes are a thousand blind windows!
Level: 124

Posts: 2948/4196
EXP: 21483132
Next: 353469

Since: 02-19-07
From: Ithaca, NY, US

Last post: 442 days
Last view: 55 days



I have to go with messiaen here. Sure, if you just hack around on a game or write quick and dirty code, "I need to increment a sprite's x position here... let's increment its x position" seems like natural reasoning; however, if you actually write a larger project with a codebase that is supposed to be flexible and accommodate for potential foreseeable and unforeseeable future changes, you will have to come up with a more contrived, and thus less immediately obvious, means of implementation. Real programming rarely is just an incremental process along the lines of "if I add this here, it will get the job done".

____________________



Ailure
Posted on 03-18-10 10:24 AM (rev. 2 of 03-18-10 10:25 AM) Link | Quote | ID: 128536

Hats
Steam Board2 group
Level: 121

Posts: 3485/3965
EXP: 19733358
Next: 323338

Since: 02-19-07
From: Sweden, Skåne

Last post: 3272 days
Last view: 2023 days
Usually you should keep yourself to more managable code, unless you need the speed from "clever code". And you should know what they say about premature optimization...

Plus I suspect todays homebrew programmers have way better debugging programs than most programmers back in the 80's/early 90's. And more knowledge of hardware quirks and tricks (such as using "undocumented opcodes" for optimization).

____________________
AIM: gamefreak1337, MSN: Emil_sim@spray.se, XMPP: ailure@xmpp.kafuka.org


Aaendi
Posted on 03-18-10 05:09 PM Link | Quote | ID: 128543


Red Koopa
Level: 27

Posts: 59/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
I know what they say about premature optimizations. I can agree with them, but I don't always find it true all the time.

I know it is important to have structure to your game engine, but some things are just better off programming raw and dirty, like enemy AI. Take an example of code from the game I'm currently making.

little_soldier:
%bounds_check($02)
lda $06
beq enemy_move_left
inc $02
bra enemy_move_right
enemy_move_left:
dec $02
enemy_move_right:
%build_sprite(#sprite_data,$02,$04,#$0000)
%tile_collision($02,#$0010,$04,#$0030,$028000,$08)
beq collision_occured
jmp end_enemy
collision_occured:
lda $06
eor #$0001
sta $06
jmp end_enemy

Notice how moving the sprite is only inc $02 or dec $02, but I'm using macros to do more complex things like tile collision and checking bounds, that are deeply connected to how my engine works.

RANDY Ruler of Zexernet
Posted on 03-21-10 06:02 AM Link | Quote | ID: 128638


Shyguy
Level: 23

Posts: 75/89
EXP: 65572
Next: 2151

Since: 07-17-07
From: Arizona, US

Last post: 4601 days
Last view: 226 days
It may not apply so much to game ROMs, but I have been known to fiddle with certain graphing calculators, & their ROMs seem to be written in C using compilers that were horrible at optimizing. I have seen code that saves registers on the stack that it never touches, among other atrocities. Sure, no sane ASM programmer would do that, but a C compiler can easily. Again, modern optimizing C compilers are much better than what they had when these systems were made.

Aaendi
Posted on 03-26-10 05:23 PM Link | Quote | ID: 128963


Red Koopa
Level: 27

Posts: 67/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
Something I could never understand. Why do people think optimizing code always causes your code to crash easily? I don't know who the hell started telling people that, and what kind of mentally insane optimizations he was doing, but I never experienced my code crashing just because I threw in an optimization?

If your code crashes because of an optimization, it's probably just because you made a typo in writing your code, not the optimization itself.

Trax
Posted on 03-26-10 11:41 PM Link | Quote | ID: 128988


Yellow Stalfos
Level: 71

Posts: 948/1145
EXP: 3028617
Next: 138497

Since: 07-06-07
From: Québec

Last post: 3598 days
Last view: 2850 days
As in the first example:

LDA foo
ADC #$00
STA foo

This operation is for numbers that are more than 1 byte long, and is used to compute remainders. Adding 0 to A will result either in 0, if the Carry Bit is clear, and 1 if the Carry Bit is set. Another thing to remember is that there could be another place in the code that points between two lines, where A gets another value, and then is stored like in the example, when returning from a subroutine...

Aaendi
Posted on 03-27-10 02:52 PM Link | Quote | ID: 128997


Red Koopa
Level: 27

Posts: 68/131
EXP: 108892
Next: 7267

Since: 10-18-09

Last post: 4641 days
Last view: 4302 days
Posted by Trax
As in the first example:

LDA foo
ADC #$00
STA foo

This operation is for numbers that are more than 1 byte long, and is used to compute remainders. Adding 0 to A will result either in 0, if the Carry Bit is clear, and 1 if the Carry Bit is set. Another thing to remember is that there could be another place in the code that points between two lines, where A gets another value, and then is stored like in the example, when returning from a subroutine...



You don't need to do that if your using a 65816 in 16-bit accumulator mode.

Trax
Posted on 03-27-10 06:07 PM Link | Quote | ID: 128999


Yellow Stalfos
Level: 71

Posts: 949/1145
EXP: 3028617
Next: 138497

Since: 07-06-07
From: Québec

Last post: 3598 days
Last view: 2850 days
Yeah, but I'm a 8-bit NES old fart...

Main - ROM Hacking - Why do homebrewers write faster code than professionals? New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.035 seconds. (340KB of memory used)
MySQL - queries: 97, rows: 132/132, time: 0.018 seconds.