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

[jonwil]

Which console systems are the easiest and hardest to develop for?

I would guess that, of the current systems, GameCube is the hardest because of all the different dev bits you would need to do anything usefull (although the sega 32XCD and saturn and the atari jaguar sound like hard to develop for too purely based on the complicated hardware they have)

As for easiest, my own thoughts is that the GBA is probobly the simplest of the current systems, no idea if there is something else that is easier.

[the_steadster]

Yup, GBA is probably the simplest. PS2 is pretty damn complex, because the architecture is non-standard. The Gamecube isn't too bad, just a plain old PPC and ATI chip. Xbox is simple if you are a PC dev, for obvious reasons (DirectX, x86)

[ASSEMbler]

Gameboy = easiest
Dreamcast = Easy (but it's not current gen by a mile anymore is it.)

Gamecube is one small T-DEV lol, probably the easiest of all the next gen systems to dev on.

I'd say in order of difficulty easiest to hardest

Gamecube
Xbox
PS2 (just because of the fucking ram)

That tiny amount of memory sure makes it hard to do a decent woman. Some games like snowblind just dropped women all together due to memory (decent ass and tits = loads more mem per char)

Hardest ever I would say goes to 32x CD.

32X to MD to CD and back. It must have been a nightmare.

Saturn was hard, but that was just due to crappy design.

[Sally]

Personally i think the Xbox is easiest for myself, but that's because of my background. For the average person i'd recomend GBA.

Saturn has to be a real bitch, i've seen the code, but i don't know anybody with a complete setup to code anymore.

The hardest, hands down, has to be Virtual Boy. I have no idea how that works, but considering i can only think of 3 complete setups (assuming Assembler's setup is complete) it has to be the hardest to code for.

[madhatter256]

Hardest ever I would say goes to 32x CD.

32X to MD to CD and back. It must have been a nightmare.

Saturn was hard, but that was just due to crappy design.

At least the 32x has native C libraries from doing some research on the PSYQ cart, but the 512kbyte RAM is just too small to do a whole game completely out of C, IMO...

[ASSEMbler]

Virtual Boy code is suprisingly simple. However, the utils are tiny tiny dos utils. The support docs would make you cry.

[MexicanGritzTaster]

It really depends on what you mean by "easy". By far, the Gameboy is the easiest to program for. The hardware is simple, there are billions of examples, and nothing "feels akward".

But if you mean by easy in "I can only program in VB/Delphi/Java", then the Dreamcast will be your baby. Even when not coding for the Windows CE platform, the development environment is very much like a lot of PC development suites.

[MexicanGritzTaster]

P.S. The Gamecube uses an ARM, not PPC processor. Its one of the things keeping it cheap.

[the_steadster]

P.S. The Gamecube uses an ARM, not PPC processor. Its one of the things keeping it cheap.


No mate, it is PPC:
http://www.nintendo.com/techspecgcn

MPU ("Microprocessor Unit")* : Custom IBM Power PC "Gekko"


Both the Ds and GBA use ARM however, GBA using ARM7 and DS using an ARM7 and an ARM9

[mairsil]

PS2 (just because of the fucking ram)

That tiny amount of memory sure makes it hard to do a decent woman. Some games like snowblind just dropped women all together due to memory (decent ass and tits = loads more mem per char)


I have never seen someone complain about the T&A difficulty aspect of PS2 programming before...
:sexy2:

[subbie]

From all the systems i've seen, I would have to say saturn (its a bloody mess) & N64.

God the N64 TMEM puts the ps2 issues to shame.
Not to mention the many different microcodes to use the gpu.

Easiest is definantly GBA IMO (easier then PC via DX or OPENGL).

Speaking of Virtua Boy, I've yet to see the official SDK but the homebrew one felt very close to GBA coding. Was VB coding like the early start to GBA coding? (never messed with a gb/gbc so i have no opinion there).

[ASSEMbler]

Gekko-PPC .. could be decent gc emu on 360 :thumbsup:

[mairsil]

Oh god, please don't start that rumor... :banghead:

[MexicanGritzTaster]

the_steadster: You are right sir. I had a momentary brain fart about the Dreamcast.

[the_steadster]

the_steadster: You are right sir. I had a momentary brain fart about the Dreamcast.


No worries mate :thumbsup:

[LocalH]

The Genesis isn't too hard to develop for - you can choose to work in ASM, C, or a variant of BASIC called BasiEgaXorz. The only access control is that on all but the first revision Genesis 1 (with the EXT port), you have to satisfy the TMSS security by writing the string "SEGA" to a certain memory location (somewhere in the $A00000 region, IIRC). The only thing that is really lacking is the fact that there isn't a fully-developed music routine (by "fully-developed" I mean including a tracker interface for creating music), but there are several tools to create Genesis graphics.

There's also a small SegaCD dev scene, but it's a harder machine to dev for.

[Piglet]

Atari Lynx had 64K of RAM and your screens, tiles and sound had to go in there. So, if you wanted a lot of frames for your main character, you had to download on the fly. The problem? It was a serial cartridge and you could only start a read at the beginning of a page so you had to split all your frames and put them at the start of a page... SEXY.

Atari Jaguar with theit own designed RISC processor... that had lower hbus priority than the 68000 so you had to do a loop doing divide instructions so the RISC chip could get onto the bus. Oh, and R30 & R31 were made index registers for said RISC chip but guess what? It didn't work. Oh, they also had a pack & unpack command to convert 5:6:5 RGB into 8:8:8 but you could do it faster than the instruction so you never used it.
The only good idea was 6 bits of green since green makes up 42% of white light. Everything else, a heap.
The CD drive had no proper controller so you had to read from 16K before where you wanted and 16K extra at the end. Then you had to encode the data so you could find the position it had ACTUALLY read. I used a modified version of GCR with the unused codes pointing to the start & end of a 256 byte block then at the end of the block a 16-bit pointer to the start of the page... and it never worked properly. Even Atari couldn't get it to work... so the project was never released... goody!

[Piglet]

Oh, best machine would have to be the Colour Gameboy. Man, you could get that little beast to really punch above it's weight!

[alphagamer]

http://www.applefritter.com/images/zombie_1-9316.jpg

on topic: my choice to start console coding with the n64 wasn't the wisest...

[_SD_]

So nearly 3 years later, what would you say about the current gen of machines?

What would you suggest as the easiest/best route for someone wanting to learn game development on current hardware?

Xbox 360 and XNA Game Studio.

PSP with custom firmware and the open source dev kit.

Fiddling with the Wii or DS.

Or something else entirely different?

[jonwil]

If tgere was support for the 3d hardware in PS3 linux, I would say that starting there would be the best option. But as there is not, XNA is the easiest way to get started if you have done any PC directx development before. That or get a modded (or debug/devkit) PS2 and enter the PS2 dev scene.

[Arkanoid]

360 is very simple which is a good thing for indie developers. Wii is technically just a Gamecube with a higher storage medium, online and a more complex controller. That explains why they are able to push the Wii way beyond the Gamecube's projected capabilities. PS3 from what I hear is a bitch to develop for. I have no experience so I can't confirm that. the GBa is one amazing piece of technology. Just check out the level of 3D capabilities this thing has.

http://www.youtube.com/watch?v=wVdOFjJ99ic&feature=related
http://www.youtube.com/watch?v=zr_DkfO_Csg&feature=related

[WarHampster]

If you want to take the *really* easy route, someone made a game maker type program for the NDS... obviously its much less powerful than using a dev kit but it could help get you into console programming: http://www.dsgamemaker.com/

If you want to take the "real" programming route, there is hardly a better place to start than with the gba. If you know C then I recommend HAM lib for getting started, as it has a huge tutorial and entire book dedicated to learning it. If you don't know C, then theres a version of basic (Dragon Basic) that was ported to the GBA... its dead now but you can still download the IDE and tutorials.

[Alchy]

Wii is technically just a Gamecube with a higher storage medium, online and a more complex controller. That explains why they are able to push the Wii way beyond the Gamecube's projected capabilities.Um, no. Go read up on what hardware the Wii has inside it. It's similar but it's not "just a Gamecube".

[Dark Seraph91]

I dont know how to code many things, But WIth the SDK and My XeDk I was able to make alot of cool small things very easily with all the samples that were provided.

So in my opinion thats the easiest system. I really dont have much experience with console programming tho.

[Ed the Nerd]

gba is very easy, It took like 2 minuts to write and compile a hello world program

[TmEE]

A system is easy when its easy when you write things in ASM, or in some high level language without any libraries whatsoever.

I'm a big fan of MD, the system basically programs itself, and is nicely designed. You can dedicate Z80 there as it runs totally independently and can access most of the outer world by itself, unlike SNES where you need tremendous amount of main CPU power...
Adding a 32X in action makes your life a bit more difficult due to the freakin address shift and that you cannot see all the ROM at once on 68K side. MCD is just prone to crashing, or so I've heard...

Next stop is Saturn for me, the sheer number of chips on its mobo makes me wanna mess with it, and I'm quite sure I will like it.

[marshallh]

N64 is a royal pain in the butt when it comes to textures and audio. Otherwise it's great.

Say your game requires a textured sky sphere. Well, on the dreamcast and any later system, you just take one big 256x256 texture and map it to a sphere. Easy.

Not so on the N64. It has a whole 4096 BYTES of texture memory. This means that you can draw at most a 32x32 32-bit RGBA image, a 32x64 16-bit 5551 texture. There's also two paletted modes. Want to use a palette? Forget about that upper 2KB of memory. So you can only store a 32x64 image in paletted mode either.

You want to do mipmapping? Cut the memory in half again. 2kb for your texture and that's it.

It's so bad that I had to write a tool specifically just to create a skysphere display list, each rectangle of the sphere has its own texture.

This is one of the worst reasons why the N64 had graphics issues. That, and the fillrate and zbuffer accesses are slow as heck because of RDRAM latency. If you want it to go faster, you have to put your framebuffers and zbuffer in different 1MB RDRAM banks.

But, I love it anyway :D :dance:

[_SD_]

I've decided to start off with XNA and an Xbox 360. It seems like a good way to learn C#. I'd also like to have a play with Dreamcast coding too.

[KIWIDOGGIE]

Programming for the Xbox 360 using the XeDK Developers kit seems easier than the Xbox 1 SDK.

XNA is too easy. Then again it doesent give you access to the 360's full resources.

[Dark Seraph91]

Programming for the Xbox 360 using the XeDK Developers kit seems easier than the Xbox 1 SDK.

XNA is too easy. Then again it doesent give you access to the 360's full resources.
I geuss sorta off topic but I have a Xedk And use the sdk with it, but ive never used XNA. What is limited with XNA? like what arent you allowed to do with xna?

[Piglet]

I don't think getting the 'hello world' output is a good guide to complexity of programming. The older consoles are simpler because they DO less. PSX was easier than PS2 and from what I have seen, the PS3 is even more of a pain.
If you use a shell, stick to C, don't use the system 100% (just %90) then maybe the latest machines are simpler than they can be for 'to-the-metal' assembler coders.
I would still argue that the Gameboy is the simplest... it does so very little...

[jollyroger]

In my humble opinion the Gameboy Advance and the first XBox are equally the easiest consoles "bang for buck", you can very quickly get something decent done with both, using some libraries and simple code.

In the hardest corner I would put the n64 and the PS3; while you can do something quickly with both, doing things properly is much more complicated and time consuming, having said that they are also amongst the platforms I like the most...

Jollyroger

[darkangel]

I don't like the Super Nintendo. It feels like Nintendo misunderstood the idea of a 16-bit video game architecture. If they didn't hire the realism-whores at Sony to design their sound chip, and if they made a simpler hardware register design for their graphics chip, and focused more on raw power instead of complexity, it could have been a better and easier system to program.

[tomaitheous]

I don't like the Super Nintendo. It feels like Nintendo misunderstood the idea of a 16-bit video game architecture. If they didn't hire the realism-whores at Sony to design their sound chip, and if they made a simpler hardware register design for their graphics chip, and focused more on raw power instead of complexity, it could have been a better and easier system to program.
I take it you've not coded for the NES, then? :icon_bigg Sound likes you want a Genesis.

The PC-Engine (or Hudson Entertainment System as it's also known) had a chance at becoming the next Nintendo console. Hudson was Nintendo's first 3rd party developer and was very close to Nintendo. They tried to license their new system to Nintendo, but the deal fell through, and NEC came along and pick it up. The SFC was in developement for a long time and you can see what looks like to be a last minute addon's to the sPPU's.

Still, the CPU being crippled by the WRAM delay cycles and the slow clock speed in general, the solution was easier to fix than say on the Genesis or PCE. However convoluted the sPPU layout was, the final output was amazing back then and no 'cart' addon of the other systems at the time was going to bring it up to the same level. At least graphics wise. PCE fans were enjoying red book audio before and after the release of the SFC.

Also, I don't see how is the SPC700 is adding anything overly complex to the system.

[darkangel]

I didn't mean raw power entirely as in cpu power, but if instead of making 8 graphic modes, they made only one mode, they could make that one mode more powerful than the 8 modes, and have it do cool things like real scaling and rotation on sprites.

For the spc700, wouldn't it have been a lot less expensive if they just had the 65816 have access to the dsp instead of having a secondary cpu running it? They could've used that extra money to make the cpu a little bit faster and I don't really expect there to be a big difference in games if it had less ram.

EDIT: I personally don't beleive slowdown was entirely the cpu's fault, I beleive it had to do with bad programming too. It's that if it were clocked faster, bad programmers wouldn't be able to screw up games as easily.

[manopac]

DS ... from not knowing the system at all to finished game in less then 2 weeks parttime - probably the easiest system I ever coded for

[tomaitheous]

I didn't mean raw power entirely as in cpu power, but if instead of making 8 graphic modes, they made only one mode, they could make that one mode more powerful than the 8 modes, and have it do cool things like real scaling and rotation on sprites.
Well, they could only do so much with so many cycles in a scanline and hblank, etc. Removing the extra modes isn't going to make the chip faster or free any spare cycles. That's why they're modes and not just features you can instantly turn on and aoff. All they really did was optimize what chip real state they for more modes. Besides, quite a few of those modes are useful.





For the spc700, wouldn't it have been a lot less expensive if they just had the 65816 have access to the dsp instead of having a secondary cpu running it? They could've used that extra money to make the cpu a little bit faster and I don't really expect there to be a big difference in games if it had less ram.

I dunno. The unit wasn't designed specifically for Nintendo. From what I've read, Sony used variants in other setups - including its own Playstation. The Playstation one is a slightly cut down version of the one in the SNES, but with more channels. Anyway, if you removed the CPU then you'd have to interface the memory into the '816 bus which complicates things (sPPU stalls the sCPU's bus every so many scanlines for memory refresh cycle - that would be an audible artifact). Having a separate dedicated CPU is also better for other audio related reasons.






EDIT: I personally don't beleive slowdown was entirely the cpu's fault, I beleive it had to do with bad programming too. It's that if it were clocked faster, bad programmers wouldn't be able to screw up games as easily.
True. The '816 is no slouch when the code is optimized, but the slow clock speed is still somewhat of a hinderance. Though there were some examples of great coding in games.

[darkangel]

Well, they could only do so much with so many cycles in a scanline and hblank, etc. Removing the extra modes isn't going to make the chip faster or free any spare cycles. That's why they're modes and not just features you can instantly turn on and aoff. All they really did was optimize what chip real state they for more modes. Besides, quite a few of those modes are useful.


I meant in a transistors count vs speed trade off. BTW, what physically makes chips faster and what physically makes faster chips cost more?


For the programmers and the slowness. I'm very surprised at how stupid people can be when programming things. I hate how programmers think optimizing code is so freaking hard. Optimizing is so freaking easy. All you have to do is program the game the using the easiest way, that's it. I hate how programmers slowly come up with stupid tricks that either barely work or makes the problem even worse and tell other programmers about the stupid trick they made up and everybody takes it and believe it's the best thing sliced bread and they're geniouses just becuase they can cram more stupid "advance" programming "trick" into their tiny little minds. While in all of my codes, every single opcode I write is an individual trick, only because I only use 1 opcode when it can do something in only 1 opcode. Other people ask others "Do you know a complicated trick of doing this opcode" and they give them a complicated trick of doing an opcode, then they think of how ingenious they are for using complex programming in the place of a simple opcode and cram it into their brain, while I know if I just use one basic opcode instead of a complicated "trick" to doing that opcode it will run a lot faster and still take up less memory. There is more to intellegance just knowing a lot of stuff. There is something called common sense that people need to be smart. Just knowing a bunch of crap doesn't make people smart, that makes them brainwashed and nothing more.

[TmEE]

when you're done with doing something the simplest way possible, some people like me will want to get more out of what they've done, so real optimization begins...

[Alchy]

For the programmers and the slowness. I'm very surprised at how stupid people can be when programming things. I hate how programmers think optimizing code is so freaking hard. Optimizing is so freaking easy. All you have to do is program the game the using the easiest way, that's it. I hate how programmers slowly come up with stupid tricks that either barely work or makes the problem even worse and tell other programmers about the stupid trick they made up and everybody takes it and believe it's the best thing sliced bread and they're geniouses just becuase they can cram more stupid "advance" programming "trick" into their tiny little minds. While in all of my codes, every single opcode I write is an individual trick, only because I only use 1 opcode when it can do something in only 1 opcode. Other people ask others "Do you know a complicated trick of doing this opcode" and they give them a complicated trick of doing an opcode, then they think of how ingenious they are for using complex programming in the place of a simple opcode and cram it into their brain, while I know if I just use one basic opcode instead of a complicated "trick" to doing that opcode it will run a lot faster and still take up less memory. There is more to intellegance just knowing a lot of stuff. There is something called common sense that people need to be smart. Just knowing a bunch of crap doesn't make people smart, that makes them brainwashed and nothing more.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?

[darkangel]

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?

[Twimfy]

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.

[mairsil]

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

Leave.

[graciano1337]

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 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?

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:

[tomaitheous]

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


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

[WarHampster]

*sigh*

Successful troll is successful.

[Alchy]

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


your to dumb to understand that you are dumb.You know nothing about me, and if your coding is as poor as your English then I feel sorry for your compiler.

[tomaitheous]

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.

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 ;-)

[Alchy]

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

[tomaitheous]

Perhaps you think this is behaviour that should go by unchecked;
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?

[Alchy]

Shall we move back on topic?I'd be up for that, but since you asked a question, it's only fair to respond:
He hasn't 'proven' himself (nore have I myself), but is that necessary to contribute to this thread?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

[darkangel]

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.

[MottZilla]

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.

[tomaitheous]

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?

[darkangel]

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?

[MottZilla]

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?

[darkangel]

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.

[mairsil]

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

[selgus]

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

[TmEE]

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

on MD, when doing 3D, the best way is using a RAM buffer and when you're done, just DMAing it into VRAM... direct VRAM manipulations will be quite a bit slower...

[selgus]

on MD, when doing 3D, the best way is using a RAM buffer and when you're done, just DMAing it into VRAM... direct VRAM manipulations will be quite a bit slower...
That is how it was done, all into the 64K RAM, and DMA'ed into VRAM. I guess I didn't make it clear that the hardware specific structure was to get the writes to RAM efficient.
--Selgus

[TmEE]

Just out of curiosiy, what MD game(s) did you work on ? And do you know anything about sound stuff that was used ? Sound stuff fascinates me as I have made a really powerful sound system for MD, though 15 years too late :/ (and I was in kinderkarten 15 years ago anyway...)

[selgus]

Just out of curiosiy, what MD game(s) did you work on ? And do you know anything about sound stuff that was used ? Sound stuff fascinates me as I have made a really powerful sound system for MD, though 15 years too late :/ (and I was in kinderkarten 15 years ago anyway...)
Nothing that was published on the Genesis, before working on XBAND Modem networked games. All my Genesis development was for my own pleasure. I did a 3D cavern demo, a Centipede game, and a bunch of other little projects.

For sound, I used the GEMS system, so just used their Z-80 driver.
--Selgus

[darkangel]

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

I could fully agree with you. On another website I made a thread about programmers not optimizing their code, and everybody answered, "because they didn't have time to fine tune their code for optimal speed." I kept on explaining them that nitpicking little pieces of code after you programmed the whole thing wouldn't help very much, enable to make a large difference you need to program it already fast to begin with. Those guys just couldn't get what I was saying to them, no matter how many times I explained to them.

The only reason developers thought the Snes was so hard to run fast is because the programmers kept waiting till the end to optimize their code and this is the only reason they struggled with it.

[MottZilla]

Well I agree with you that a certain amount of it was the developer's fault but at the same time the SNES CPU was indeed slow. Atleast slower than the Genesis. Mainly I just find it annoying that the SNES CPU was certainly capable of running faster than the pathetic 2.68mhz yet they let it be that.

[TmEE]

Nothing that was published on the Genesis, before working on XBAND Modem networked games. All my Genesis development was for my own pleasure. I did a 3D cavern demo, a Centipede game, and a bunch of other little projects.

For sound, I used the GEMS system, so just used their Z-80 driver.
--Selgus

I guess there isn't any of your MD stuff left ? It would be fun if there were and you'd be willing to give anything out :)

GEMS sucks :P As much as I could run the soft that came with it, things were rather user-hostile, at least compared to my sound system :)
The Z80 code is a mess aswell ;)

[selgus]

I guess there isn't any of your MD stuff left ? It would be fun if there were and you'd be willing to give anything out :)

GEMS sucks :P As much as I could run the soft that came with it, things were rather user-hostile, at least compared to my sound system :)
The Z80 code is a mess aswell ;)
I'm sure I could dig up some of my old stuff, and maybe post bits and pieces of it here. It's all 68K assembly, but it well commented (I personally believe in spending the time when writing code to comment it well so anyone reading it doesn't have to guess the intent).

I've already posted some N64 MIPS assembly I have done on this site.

GEMS did the job for me, so I treated it like a black-box. At that time, I wasn't an expert in Z-80 so it probably did save me a lot of time. As I used to tell my audio director, they are called "video" games, not "audio" games. ;-)
--Selgus

[Yakumo]

GEMS sucks :P As much as I could run the soft that came with it, things were rather user-hostile, at least compared to my sound system :)
The Z80 code is a mess aswell ;)GEMS sucks from a listeners point of view too. Bloody awful screechy sound from it. TmEE, what do you think of Technosoft's sound engine, especiallyt hat used in Thunder Force 4?

Yakumo

[TmEE]

GEMS sucks from a listeners point of view too. Bloody awful screechy sound from it. TmEE, what do you think of Technosoft's sound engine, especiallyt hat used in Thunder Force 4?

Techosoft's sound engine is doing wonders with FM, but it fails miserably at PCM :( When the tools would ever surface, I doubt nothing much can be done until someone translates them from JP to EN...
I can dream of TF4 Stage8 with PCM drums :drool:




I'm sure I could dig up some of my old stuff, and maybe post bits and pieces of it here. It's all 68K assembly, but it well commented (I personally believe in spending the time when writing code to comment it well so anyone reading it doesn't have to guess the intent).

Sounds fun :) I really should start commenting my code... when you write ASM and have no comments its fine, but after some time has passed and you think of further optimizations, you'll go crazy trying to figure out what your old code does, especially when its already very optimized :P



GEMS did the job for me, so I treated it like a black-box. At that time, I wasn't an expert in Z-80 so it probably did save me a lot of time. As I used to tell my audio director, they are called "video" games, not "audio" games. ;-)

Hehe :) some current games could be called audio games though :P

Mr. Steve Snake once told me that GEMS was the only tool that "regular musicians" could use as it required no programming knowledge... that explains the fact it was used by some 200 games.... which of few sound good :/