DKC Atlas Forum

[Aaendi]

Name the stupidest programming myths you ever heard. I know a lot of them, but I don't want to spoil this thread for anyone.

[Simion32]

"Don't optimize your program because the compiler will handle it and there's way more than enough memory for your needs."
Bull because this leads to sloppy programming. Also, you don't own the entire RAM chips (unless, that is, you're writing an OS).

"Use .NET for everything, .NET is fast and efficient and doesn't take that much memory."
Bull because .NET is so freaking bloated. Over several GB in size. And programs made in it use way too much memory RAM-wise, too. It should only be used in private business situations, period. And only if it's absolutely needed (validation by the CLR).

[Aaendi]

"The faster the CPU is, the faster it can scroll a background or move a sprite on the screen."

[Aaendi]

"Don't optimize your program because the compiler will handle it and there's way more than enough memory for your needs."
Bull because this leads to sloppy programming. Also, you don't own the entire RAM chips (unless, that is, you're writing an OS).

This reminds me of the phrase, "Premature optimization is the root of all evil."

Oh so that means I can program a fundamentally inefficient architecture, and wait until the end of development to start fine-tuning everything?

[Aaendi]

I don't know if this is can be considered a myth, but I notice when people talk about how fast the 68k is, they talk as if number values magically appear in registers as needed, not to mention the fact that

Spoiler!

immediate addressing instructions take 8 cycles!

[Kiddy14]

My Programming professor used to tell us we shouldn't worry much about optimizing because "the difference in processing time is so small we wouldn't even notice." He told us to focus in understanding the program first, though.
Of course, maybe he's a little right, but I almost always ignored him =P

[Aaendi]

"the difference in processing time is so small we wouldn't even notice."

...unless your one of those programmers that tries to be super-dooper organized who is like "Now I am going to jump to a subroutine that adds the two bytes together."

[Simion32]

That would be a pointless jump. It's like putting if(true) ...although most compilers are smart enough to optimize that out.

That assumption also really falls when you are working with graphics, because you're going to need all the time you can get. Seriously, just copying 1280x1024x32bit on this PC results in at least 21% (!!!!) PC usage (and my software MMX routine actually outruns the graphics card at its own game, hah).

Any optimization of the drawing/copy code will make it faster, period.

[Aaendi]

Something I find annoying is how much 32-bit instructions get hyped. I've never seen an SNES game with levels longer than 256 screens long! The only time I ever use 32-bit arithmatic is when a decimal point is needed.

[Simion32]

Actually that's just due to physical memory limits and game architecture on the SNES. Word size on the processor really has nothing to do with level length in the first place. The longest level in the DKC trilogy is around 24,500 pixels wide, about 3/8 of 256 "screens". Honestly, I'd love to see a 65536-pixel-long DKC2 roller coaster level!

I'd think 32bit is better, but only if your circumstances add up to an actual speed or performance gain (or in rare cases the ability to do some special operation). For instance, if you are running on a 32bit PC, that is probably the fastest datatype for use in a program. Why? Because it avoids the compiler having to shift around and manipulate bits to ensure the value is operated on correctly when you convert between small types and the system int type. Also, truecolor ARGB graphics are 32bit.

Random thing I never knew a month or so ago due to this "myth" of there being no multiply or divide on the SNES:
The SNES does have division and multiplication registers, one of the multiplication registers actually can result in up to 3-byte long values.

[Aaendi]

On the 65816, there is no 32-bit instructions so you have to use more than one instruction.

[Simion32]

I'm aware of that; I do have experience in 65c816 ASM.

I'm just trying to say, that just because you don't have 32bit doesn't mean you can't make the level that long. You can have a level as large as you want (within ROM space limits) using the same old 16-bit tile format.

Yeah it'd require a little glue to handle bank switches during reading the level, but that's still not related to the actual tile data.

[Aaendi]

I'm aware of that; I do have experience in 65c816 ASM.

I'm just trying to say, that just because you don't have 32bit doesn't mean you can't make the level that long. You can have a level as large as you want (within ROM space limits) using the same old 16-bit tile format.

Yeah it'd require a little glue to handle bank switches during reading the level, but that's still not related to the actual tile data.

Oh, I was refering to object coordinates.

[Aaendi]

Here is something I hear a lot.

"the most popular companies have the best programmers"

Then why can I get significantly more sprites/objects/enemies onscreen than Capcom and Konami could without lagging?