About CPU speed,



When, say, my 2Ghz deliverers.. I dunno 10 realtime trueverbs (a go(o)d reverb), then it's simply a matter of how many reverbs or other DSPs I need. In most cases, it's *I* who want a faster CPU, not the software! And since DSP algo's like delaylines/reverbs are quite optimized, probably in ASM since it's not so hard to code, I don't think it's lazy code here..

Here's a quote I remember:

Over the past 15 years, computers have become 1000 times faster.

In this same period, programmers have successfully compensated for that.

There's some other thing involved in today's software releases. MONEY

Programmers don't get all the time they need to fix all spaghetti and bugs. The marketing director just want to release this game or that app and IF there are any bugs noticed by the end-user: "We'll release a service pack, or software update, or gameplay fix, or whatever"...



This wasn't even an option 20 years back. How in the H*LL would you receive an update for your new MSX cassette game "Robot Wars" when you discovered it has bugs???

Not to mention ROMS. So in those times, marketing directors simply couldn't push programmers to release shitty code. Otherwise they all would be out of a job very quickly. With the internet, it's of less importance (commercially)if all bugs are fixed. They'll just release a fix.



I really don't think coders don't know what they're doing. If you arrive at the office, open your dev tool and think "what the hell did I write?" Then you surely know you've got to fix something

indeed..



And the most frustrated ppl are scene/ex-scene ppl working at such companies. They all want to output the best optimized and most structured code there is, but they simply have a deadline to match.



I dunno in detail how badly the classic coders from before the 80's revolution, the coders with long beards, light-emitting-eyes and sandals, want to optimize everything, but to me it's as if the real optimizing started from the 80's/90's when coders found out that optimizing made their demos/games have more frames.

The coders before 1980 knew how to squeeze the last bit out of their so limited systems quite well. Memory was so expensive! and cpu's so slow that every trick had to be used.



For example i managed with a 64K PDP-11 to let 8 users with terminals do very specialized type of wordprocessing, including a printer queue. 32K was the operating system, the other 32K for the program. And the cpu was comparable to a Z80 at 4 MHz.

Ofcourse this was in a highlevel language (Pascal) with some routines in Fortran or assembler like sorting. The system was programmed with a team of 3 programmers. Readable and maintainable code was therefore essential, also we had a paying customer who inspected our code at our request! We spent 150 mandays to build the system. About 1/3 was spent in optimizing, and that was a waste of time to cope with the limited hardware because it did not add any quality for the user except acceptable performance.

The system did have a hard disk of 5 Mb, virtual memory paging and the total system price was 100K guilders for the hardware.

The system was used 10 years at fifteen locations, and the software had 5 major revisions by different groups of programmers. If that software had not been written in a clean, readable, structured and documented way that would have been impossible. It it had been written in pure assembler we never would have finished it in the same time, (even with the PDP-11: a nice clean instruction set, much more orthogonal than the Z80) and maintenance would have been real difficult.



I did not have a beard then but a moustache those years And software engineering was a profession already in these days requiring education and experience.

yeahyeah I know that, about the beard, I'm just trying to find the 100% opposite of a scener

With more people working on one program, and sources that are to be maintained in the future, probably combining ASM with languages as Pascal or C is a good idea. For products like games and demos I think ASM is the only way to go on limited systems like MSX. I'm not saying you cannot create games in Pascal (there are perfect examples that prove it can be done), btu you can do a LOT more in ASM.

But then again, most games aren't that big.. an RPG, the scale of sd-snatcher, is the biggest game to code I know. Most shooters etc. are quite small.. it's the gfx/music/maps which makes it big.



Did we ever realise that Aleste is just a classic space-invaders with a scrolling background?



When you work on REALLY big long-term projects, photoshop-size, even c++ is not gonna work 100%. (well, c++ may work so at first sight, but after a while you'll discover that everything's souped-up and needs to be rewritten again)



imo, eventually c++ will be replaced by component-based languages. (script-based)

I am convinced that ASM is the best language for programming games (critical speed software) in slow-clocked systems like MSX...



BUT have you noticed that all spanish MSX software recently published (excluding MATRA) is coded using MSX-BASIC plus NESTOR BASIC? That means: BUBBLE RAIN, MSX HOT NUMBERS, CAT'N'MOUSE and many others. And they are really good games!



My post is only to add a new idea to the discussion: the problem is not only that coders are loosing their capabilities to produce fast, accurate and optimized code. What is definetly lost is CREATIVITY. Imagination is NOWHERE!



Any language is good to create a GOOD GAME if the IDEA is GOOD too! MSX cannot compete technically with 3D awesome games running at 201312032194788 teraFlops, but it can reach even better gameplay with good gaming concepts.



And getting apart from the main topic: has anyone considered to code a ROGUE (HACK, Angaband, what-so-ever) game for the MSX system? It could be great just adding some well-done graphics.



Hey! I am so sorry for my english. But you can get the main idea, don't you?

Quote:

BUT have you noticed that all spanish MSX software recently published (excluding MATRA) is coded using MSX-BASIC plus NESTOR BASIC? That means: BUBBLE RAIN, MSX HOT NUMBERS, CAT'N'MOUSE and many others. And they are really good games!

What can I say? Nestor basic rulez!! In Japan, a most remaining developers use DM-System2 by Gigamix to be able to develop new products quickly. Most of them end up on NV, a diskmagazine of Syntax.

Quote:

Any language is good to create a GOOD GAME if the IDEA is GOOD too! MSX cannot compete technically with 3D awesome games running at 201312032194788 teraFlops, but it can reach even better gameplay with good gaming concepts.

This is 100% absolutely true to me

Quote:

Hey! I am so sorry for my english. But you can get the main idea, don't you?

Your English is understandable, and your contributions are more than welcome.

True! Some of the MSX-BASIC listings published in the japanese MSX Fan magazine are very fun to play. But that's where it ends. What using ASM on MSX allows you to do is add a lot of polish to a game.



You will see this when my current project is finished. The game itself is fairly simple and could be programmed in BASIC without problems. But the polish I've been able to add with highly optimized assembler is really worth the extra trouble.



The way wolf_ describes Aleste is oversimplified too. Its programming is awesome! While a Space Invaders can be programmed in MSX-BASIC without trouble, Aleste 2 goes to the limits of the Z80. From the amount of objects on the screen I can see it must be using highly optimized routines. Especially the spread-shots and homing weapons are impressive from a coding standpoint and how they did it with just 64K RAM is beyond me. Kudos to Compile!

wahahaa, i programmed hamaraja night in NestorBASIC. It went well until NBASIC started to complain about memory lack. I could program sources but they mustnt exceed the 6.8 Kb size!

Is hamaraja night the only project you ever coded for MSX? The final version was coded in ASM. right? I'm still quite curious about the results.

the 'it's all about the money' issue is what kills me..

That's exactly the kind of attitude I disslike.



the 'as long as it works 50%, it's okay for me' thing is just wack. Indeed I am a frustrated (ex)scene coder, I know...

This issue is not new, I've been discussing it since the famous eighties already!

My message is to the coders to not give in, and make goods softs.

Fret for your lawsuit, shake your moneymaker (or whatever)

(and to be honest, being a GOOD coder is still a hardjob)



'it's the outcome that counts' (the nestor basic thing)..

true.

But would it not be nice to actually have a BUGFREE outcome? something that really puts your cpu at work, just for our entertainment..



Nice to see all these different opions piled up and packed in a forum. Again, this issue has been bugging me for over 10 years now.



As long as your being true to yourself and never give up to learn anything new, things are looking good my friend.



lateralus (gotta go to work.... make more sloppy code )

Quote:

wahahaa, i programmed hamaraja night in NestorBASIC. It went well until NBASIC started to complain about memory lack. I could program sources but they mustnt exceed the 6.8 Kb size!

And what are you laughing about? If these games are programmed in NestorBasic, it's pretty impressive, don't you think?

Quote:

Is hamaraja night the only project you ever coded for MSX? The final version was coded in ASM. right? I'm still quite curious about the results.

Me too But Mark has nothing to do with that version... The ASM version follows the rules of the original somewhat better.

And about the optimized coding:

I think I optimize too much on msx. I spend too much time looking how something can be done faster. It really slows down the development.