Which system is the easiest (and hardest) to dev for?

You talk up your abilities and trash talk other developers, so let's see you back it. How many full games have you made, and where can we try them out?

 

Hi my name is Alchemy and I like to make posts that start flame wars and I like to troll other people because I love people yelling at me back.

Yeah like YOU ever made a game yourself or even a demo yourself. You probably don't even know how assembly works and just copy and paste statements you hear on other websites.

Getting the sPPU to work and knowing how to optimize codes are TWO DIFFERENT things and you don't need to know about one of them thing to know the other.

How do I know I'm good at optimizing, it's called cycle counting. It's something you should have learned from watching Sesame Street, but apparantly you didn't and still don't.

You were born ignorant and you'll die ignorant, and you'll always be blisfully unaware of how dumb you really are, because your to dumb to understand that you are dumb.

I'm sorry for the insults, but apparantly you wanted to start it.

And PLEASE END IT! DON'T YOU KNOW HOW MUCH I HATE YELLING AT PEOPLE? I HATE IT! WHY DOES EVERYBODY LOVE YELLING AT PEOPLE.

I'm tired of going from website to website only finding out that they all like to start fights. Why am I the only one who hates starting fights?

 

Erm...you have started the fight, Alchy merely pointed out that you'd trash talked every coder in the industry. Perhaps if you'd provided some examples of sloppy code and carefully explained why those developers had screwed up then maybe this wouldn't have escalated.

Although you are pointing out a general idea of poor programming, you do kinda rant repeatedly, I got your point in the first few senteneces.

Alchy said...'how many games have you made?' Which considering the content of your posts was quite appropriate.

Your response (instead of listing any experience or stating that it was just your opinion) was - "Hi my name is Alchemy and I like to make posts that start flame wars and I like to troll other people because I love people yelling at me back."

I haven't heard anyone talk like that since first school.

Nobody on assembler starts flame wars, we defend people when it's due and I think Alchy made a good call to check your background before you go bad mouthing coders in general, some of which may reside on these boards.

Next time either give some reason for your rant or state that it's just an opinion.

 

Leave.

 

Sounds like you have something of history of fighting over the internet. You seriously sound really immature. You just joined the forums and you're already hurling insults at a senior board member. You should either leave or get your act together before you get banned. :nod:

 

Not to get in the middle of your guys little gang up, but..

How is that not an insult? He basically told darkangel that he was 'full of shit'. That's a personal attack. There are so many other ways to phrase that question without it being a personal attack. Alchy, since you brought it up - you have some qualifications yourself?

Anyway, I can tell you that any who's stepped through game code, and that actually have a good level of understanding, will find quite a few example of 'lazy' code. Some programmers don't care and want clearity of code over complexity, others might not have had the time.

That said. Darkangel, you kinda lost me somewhere through the middle of that, but if it was just reiteration of the first few lines then I can't really see this happening for assembly unless the coder(s) in question were less experienced. Then again, anyone who's learning assembly is counting cycles from the beginning anyway. Chopping cycles is the end product, but the means aren't always obivous.

 

*sigh*

Successful troll is successful.

 

None worth mentioning, and consequently, I don't go around claiming I'm some kind of genius and that everyone else in the industry is an idiot. The point is, if this guy is going to talk shit about other developers, then he needs to back up what he's saying. This is not a personal attack (unlike his posts, which have been universally inflammatory), it's simply the rules of engagement.

You know nothing about me, and if your coding is as poor as your English then I feel sorry for your compiler.

 

Programmer != developer. There are hobbiest programmers, novice programmers, hacker programmers, etc. Not everyone that codes is instantly a 'developer' in its general context. Honestly, I'm not sure how you got 'developers' out of his rant. He was pretty vague about who he was talking about and really vague on details. If anything, it sounds like he's referring to a familiar group of people(classmates?) or a scene that he's familiar with.

And as far as I can see, the only thing you contributed to the thread was to drop an insult directly at darkangel for whatever reason. Just my observations ;-)

 

In the other thread he was trash-talking Japanese SNES developers from back in the day. So no, he's talking shit about professional coders and so far hasn't proved anything about himself except a short temper and an overdose of arrogance. Perhaps you think this is behaviour that should go by unchecked; given that two other members went so far as to suggest he should leave, I don't think many share your viewpoint.

By the way, a "personal attack" is something like "you are a dick" or "you don't know anything". I asked him to back up what he was saying and he came back like I'd insulted his mother. I don't think I have a lot to be apologising for.

 

Please don't make abserd assumptions or put words in my mouth. I do think his response was immature and explosive, but you're the one that brought it on. He could have easily responsed with just a simple 'snark' reply. He gets not excuse from me, but that doesn't change the fact you contributed nothing but to 'rouse him up. And if you don't think the tone of your reply was anything but friendly and calling 'bullshit' isn't a direct insult, well.. then you might want to have a re-look over your own social skillset. Poke the dog with a stick and complain when it bites you ;-)

And I did read the other thread. He was specific in that thread about SNES developers, he was not specific about anyone in this thread. It had a more personal feel to it. And I doubt he knew/knows those Japanese SNES developers. So I don't see the relevance.

He hasn't 'proven' himself (nore have I myself), but is that necessary to contribute to this thread? It's more of a casual discussion.

Shall we move back on topic?

 

I'd be up for that, but since you asked a question, it's only fair to respond:

Peculiar really, I feel like I've answered this pretty much twice now, but whatever. Nobody has to "prove" themselves unless they start making arrogant claims. If you say you're smarter than everyone else, and that other people can't code for shit, someone will call you up on it.

/drama

 

I'm sorry if I sounded like I'm a fanboy ranter. I am a very math oriented person, I'm in BC calculus and I always use a lot of math to test how fast cpus are to each other. That being said, I know for a fact that the Super Nintendo could've had a lot less slowdown with the same cpu if the programmers actually programmed it right. Very few people agree with me, because they don't do the math for themselves and only rely on what other people tell them. This problem gets worse every year, and rarely ever do I get anyone who understands or agrees with me.

 

You should realize that most of all they are concerned about getting the game done on time/on budget. So if the game functions but suffers some slowdown, too bad, perhaps time and money did not allow them to go and optimize code to reduce or eliminate the problem.

I do agree with you that some games that suffer slowdown probably could have been coded better to prevent that problem. It's a shame they didn't do what Calpis has mentioned before where they could have used faster WRAM in the SNES so the CPU could have run faster, even if you had to copy the game loop code into RAM and execute it from there.

 

A lot of people that are not intimately familiar with 65x architecture usually can't see the preformance with in. The manner of optimized code with much different than 68k or even z80. And of course there are people who don't have experience, but have looked over the processor and think, "Wow- only 3 registers? And only 1 for math operations? No wonder why it's so slow". Never mind the fact that the C64 with a 1mhz original 65x did some amazing things, let alone the PC-Engine's 65x variant with shooters of lots of objects on screen and blazing speed without slowdown - rivaling 68k Genesis shooters with ease.

That said, performance comes at a cost with the 65x arch. Time. It's not directly straight forward optimizing - IMO. On the '816 version, it's less of an issue (mostly because of quick long mode access and 16bit arrays) but it's still there. And then there's the fact that quite a few instructions are slower than the 8bit versions (by 25% or more) for the equivalant 8bit operation. I guess it's nice that you can switch between 8 and 16bit mode, but you still have the overhead of that making it less productive and the complexity of the code goes back up.

Optimizations for the 65x arch are very specific in type. Feed it something like a more complex script logic/engine and you loose some of that due to the dynamic nature of the situation. The more dynamic the needs, the less efficient the 65x becomes or the larger the code gets to compensate/make up for speed (logic unrolling gives you a lot of redundant code). It's not uncommon to see the better coded games for the PCE take advantage of an all ram environment and use self modifying code. I don't remember seeing any SFC carts with extra ram (for this kinda purpose), but then again the trend seemed to be just to put additional processors on the cart.

I've always wondered if some game companies wrote scipt compilers. Something that has hardcoded code structures for a level to perform a whatever specific function, but generated by the script compiler at build time. One could go through the compiled code and optimize once the level is OK'd by upper management. The rule goes; if I've thought of it, then someone else has too. Anyone have an examples or experience with this?

 

Even if the Super Nintendo did have a slower cpu than the Genesis, it still shouldn't have made the gigantic night and day difference it did.

It was supposed to be half it's speed, but in most games it appears like it's 1/50 the speed instead. This is what scares me. Who are these people who make these games, and what are they doing that is so inefficient and why are they doing it?

 

Half? 2.68mhz versus 7.5mhz? That doesn't seem like half. Even if you had FastROM to go at 3.58mhz or so, it only was for ROM accesses. The speed would be less every time it accesses WRAM or Registers. So the SNES CPU certainly was slower.

What games in specific do you see suffering horrible slowdown? I know Gradius 3 suffers slowdown when you get 4 options and lasers. But the reason there I bet is because each segment of the four laser beams is testing collision, rather than the beam as a whole which might have been more done differently and been less of an impact. What other games have such terrible slowdown that you've noticed?

 

A lot of games, can't remember all of them.

Even if it was 1/3 it's speed, it still wasn't a big enough difference for one system to blanket the screen with sprites with no slowdown, and the other to have major slowdown with 4 or 5 onscreen sprites. Since when does 5x3=100?

If you want to get technical, if someone actually know how to make optimize both 65816 code and 68000 code equally, the 65816 will always take less cycles though I don't really know the exact ratio. What you need to know for optimizing the 65816 is that using most 68000 optimizations on the 65816 would only make the code worse, while vise-versa, there are a lot of 65816 optimizations that won't work well on the 68000 that programmers get taught not to use, but don't get that you shouldn't do it only on the 68000, on other cpus it's fine.

For example, loading 5 16-bit value into 5 consecutive register, on the 68000 they teach you to do this:

MOVE 1st address,A0
MOVE 1st value,(A0)+
MOVE 2nd value,(A0)+
MOVE 3rd value,(A0)+
MOVE 4th value,(A0)+
MOVE 5th value,(A0)

because it's a lot faster than this:

MOVE 1st value,(1st address)
MOVE 2nd value,(2nd address)
MOVE 3rd value,(3rd address)
MOVE 4th value,(4th address)
MOVE 5th value,(5th address)

While it is the complete opposite on the 65816.

This:

LDX 1st address
LDA 1st value
STA $00,x
INX
INX
LDA 2nd value
STA $00,x
INX
INX
LDA 3rd value
STA $00,x
INX
INX
LDA 4th value
STA $00,x
INX
INX
LDA 5th value
STA $00,x

is actually a lot slower than:

LDA 1st value
STA 1st address
LDA 2nd value
STA 2nd address
LDA 3rd value
STA 3rd address
LDA 4th value
STA 4th address
LDA 5th value
STA 5th address

Yet they do it the slow way just because they were trained by doing it the way they would on the 68000.

And that thing about the Gradius having lazers using 4 collision boxes. It's mistakes like these that I will never understand the reasoning, and for some reason you see them all the time in Super Nintendo game source codes, but they just never show up Sega Genesis game source codes, and I just don't understand that.

 

Just programming the code is not all there is to game design. There could be legitimate reasons (unoptimized automatic compilation, crunch) or illegitimate ones (laziness, cut and paste syndrome).

 

It seems from briefly reading this thread, that some are pointing to low level optimizations and attributing that to slow-downs. While this could be a percentage hit to performance, my experience has shown these types of drastic slow-downs are design/porting decisions made at the high level.

Shaving a few cycles here and there by using better addressing modes, could add up in the long-run, but an algorithmic or design tailored to the specific hardware will have a much larger impact.

Case and point-- I once did a 3D polygonal renderer on the Genesis, by dynamically writing into a character map. The way I got it to work in real-time was to design it to the Genesis' hardware, pre-computing as much of the math as possible in tables, organizing the routines to handle the memory layout of the character map data and unrolling loops. There are other perfectly acceptable other approaches I could have made at the high level, which I am sure would have had very different performance results (some may have been better, some worse).

I have also seen this type of slow-down result when people port from one platform to another, and try to use the same high level approach done in the original SKU.

Just to be clear, I am not saying knowing the instruction set inside and out, and tips/tricks are of no use; they just come second to the higher level algorithm.

Back to the original thread, the easiest system to program for is probably the one you know the best, and all it's limitations/strengths. I was quite happy how quickly the 6502 came back to me, after not using it for decades. :icon_bigg
--Selgus