Why is the homebrew scene on the Amiga not as impressive...

[Mrs Beanbag]

Originally Posted by idrougge

For the same reason, I use mostly gosubs in my current Blitz project, instead of the tidier functions and statements. When I was programming in AMOS, I only used procedures, but Blitz's (otherwise horrible) manual was friendly enough to suggest the use of gosubs in the chapter on optimisations.

i'm surprised at Blitz, i'd have expected it would be better than that.

[Dunny]

I suppose that functional programming (or using procedures/functions imperatively) will always be slower than GOTO/GOSUB but we now have CPUs fast enough for it not to matter. Go back down to a 7MHz miggy though, and the difference in performance might actually be large enough to be detrimental.

D.

[Mrs Beanbag]

i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.

[Dunny]

Originally Posted by Mrs Beanbag

i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.

How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.

That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.

D.

[idrougge]

Originally Posted by Mrs Beanbag

i'm surprised at Blitz, i'd have expected it would be better than that.

Well, so was I, but I'm not convinced that other languages have function calls for free.

[idrougge]

Originally Posted by Mrs Beanbag

i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.

I actually think you are on to something here. I have read that a Blitz function that has no private variables is just as fast as a gosub.

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.

Behold, you yet-not-fully-learned kittens in the arts of code, this creature here speaks the truth!

Even some of the compilers of the old days (gcc) were able to generate efficient function calls. Of course these would not be as great as assembly-and-love-and-effort-made ones but still fast enough to not have a major influence on execution speed.
And if they did not, there was still popt, the nice peephole optimizer of Samuel Devulder which was capable of removing much of the fluff of not-so-lean function calls.

Originally Posted by Dunny

How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.[/url]

We haz a lot!
vbcc for one, does generate good function calls code, gcc is not too bad, and I'll bet that LLVM will too when the 68k back end will be finished.

Originally Posted by Dunny

That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.

Look no further than vbcc as I mentioned above.

Originally Posted by idrougge

Well, so was I, but I'm not convinced that other languages have function calls for free.

Function calls are very cheap in the 68k world unless the interpreter/compiler is doing something very wrong. Early C compilers (and some late as well) on the Amiga tended to use LINK/UNLINK instructions for function calls which can have their use but are generally very slow and useless but this era is over.

As Mrs Beanbag pointed with her usual reasonableness, there is close to no conceptual difference between gosub and a function call (especially if you do not pass parameters) so the only explanation for Blitz Basic behaviour is well... that it is likely very ill conceived.

Originally Posted by idrougge

I actually think you are on to something here. I have read that a Blitz function that has no private variables is just as fast as a gosub.

They must have been smoking kangaroos's fur when they wrote this stuff.

I wish there was an IDE on the Amiga configurable enough to work straight out of the box with external languages (AmigaE, C, Arexx, etc.) because I'm fairly convinced that the reason AMOS and BlitzBasic still have so many adepts is that they provide an integrated development environment which helps non-experts feel secure enough which in turns allows them to experiment.

Having to learn how to configure and tie several non connected pieces together before one can start coding a simple hello world is indeed understandably dissuasive.

[beezle]

I can't help but notice the trend of people being quickly dismissive of things they're not particularly familiar with here.
Yes, there's some areas where a fish is a fish, but judgements are being passed and opinions being made based on what people know, while disregarding what they don't.

End results are what matters, and as such it seems crazy to write off, for example, blitz, which has has been used to create pretty high quality software many times in the past.

Just an observation really.

[ReadOnlyCat]

Originally Posted by beezle

I can't help but notice the trend of people being quickly dismissive of things they're not particularly familiar with here.
Yes, there's some areas where a fish is a fish, but judgements are being passed and opinions being made based on what people know, while disregarding what they don't.

End results are what matters, and as such it seems crazy to write off, for example, blitz, which has has been used to create pretty high quality software many times in the past.

As seducing as your argument may sound, it does not support your conclusion:

• Blitz: used to create many high quality software on the Amiga.
• C and Assembly: used to create 99% of high quality software on the Amiga.

So, yes, _some_ high quality programs were made in Blitz, but _most_ high quality programs were not.
_Some_ good games were made in Blitz (I know none but I'm sure there are), but _most_ great games were not made with Blitz or AMOS.

From a purely statistical point of view if end results matter, then not choosing Blitz seems much safer.

But from a technical point of view, if Blitz was so suitable for writing games, it would have been more used. Experienced assembly and C programmers would have had no issue to adapt to it (because frankly it's much simpler than both) if it really had made them more productive but the reason for these statistics is that BASICs are in the general case not suited to build more than moderately complex programs. The "many" you are talking about are exceptions, not the norm.

I might sound quickly dismissive, but my opinion of BASIC was forged over years of coding experience, about 30 total, of which 17 professionally, in about 15 languages, I did not come to think bad of BASIC overnight.
As for familiarity, I breathed BASIC from 13 to 18 on different computers (with brief incursions into assembly). I was a great GFA Basic fan which I bought along with its compiler and used it extensively to prototype a lot of ideas on my Amiga. Before I knew better, I used to love BASIC.

BASICs are great to learn the rudiments of code, but that's where it ends as well. They do not provide abstractions which are absolutely necessary for programming any moderately complex program. And any interesting game is necessarily a moderately complex program.

It says a lot that even though assembly language provides even less abstractions than BASIC and requires way more effort, it is still more suitable to create games on the Amiga. The few advantages that BASIC has over assembly are not enough to compensate for its structural deficiencies or its bad implementation.

Regarding the GOSUB issue, let me explain why I made the hypothesis that the Blitz team was smoking weird animal substances:

In computing theory, GOSUB and functions are fundamentally the same abstraction: there are no practical and theoretical reasons to treat them differently, regardless of whether they have variables or not, and a compiler will produce the same assembly code for both. This is the 101 of compiler engineering and is taught in computing science classes at the university and the only explanation for a difference is that Blitz is badly implemented, really badly because frankly this is a long solved issue in computing science.
The fact that variables cause a speed difference also smells strongly of bad design. Local variables are handled using the processor stack and they do not cause any sensible additional cost in both cases. Incrementing the stack pointer is really cheap and would make a difference only for extremely short functions.

Now, maybe I was wrong about the type of animal they used for the smoking but I'm sure that they were not as lucid as they should have been when they designed the compiler.

But more importantly, what do you think will make your program more efficient?
A better structure, better abstractions, better algorithms or choosing GOSUB over functions/procedures?
I'm sure you would say it is the former but these kinds of issues are symptomatic of BASICs: they are so deficient that they encourage local optimization over program and data structure. The speed of your program should depend on your code structure, not on using keyword X instead of keyword Y otherwise it means that the machinery of the language consumes more resources than your own code!

I am sorry if I gave you the impression that I had some irrational and impulsive dislike of Blitz but despite what you say I did give very technical explanations in my initial post, I hope nevertheless that I cleared away the impression that it was lack of familiarity with Blitz which drove my opinion. I used to think a lot of good from AMOS and Blitz but that was before I learned better.

BASIC is like sugar: approachable, easy and sweet. But if you have any long term plans you should get away from it.

May a million kittens hug you tenderly!
(Not at the same time preferably.)

[beezle]

Not to get drawn into any "I've been doing this for x amount of time" argument, but I'm pretty well versed in the theory. I started programming in 1980 on a Tandy coco1 and have used many languages on many machines since.
I specifically mentioned blitz, as it has been shown to be capable of good results. In fact Andrew Braybrook has even suggested 2nd to asm blitz is the best language on the Amiga for producing fast moving arcade style games.
Gloom and Skid marks are good examples, even if they do use some inline asm.

Why more software wasn't produced with it is probably more to do with portability and paradigms than capabilities. Even I use c more, despite liking blitz. My observation was exactly that. An observation. Not any sort of loyalty or particular fondness for basic variants.

AMOS is also a good example of judging a language by end results, however I opted to use blitz as an example, because positive end results resonate my point better than negative ones (ie. Amos, while fun, doesn't typically produce good results).

[4mat_]

Speaking as a freelancer back then, by the end of 1992 Amiga-specific work was very thin on the ground and pretty much dead by the end of 1993. It was still being used to prototype ideas for consoles, and in the art/sound departments, but as a going concern, no. So any language released after that point was going to have a tough time. I do remember doing the music for one Blitz project (edit: not Super Tennis, some similar name) but that got canned. (it was on the cover of a very late Amiga Power iirc)

Personally I'm quite a big fan of the Blitz range on PC, I still use Max to write quick dev tools because it's so fast to get graphical utilities made within a few lines. (instant access to gfx screen, input, i/o) I did use the follow-up Monkey for a year or so (wrote a couple of engines for Flash/HTML5) but switched over to Unity in the last year.

[Retro1234]

If id have known it was Fishy I wouldnt have bothered - you dont know how many times this guys says hes going to convert this game and that game ......
Thanks
.
.
.
.
http://www.amiga.org/forums/showthre...787#post768787

[beezle]

Not a bad start, but really its not doing much. Just a simple tile based scroller. Very jerky too. I'm going to guess you're updating your tiles a row at a time? It shows when anything else is happening other than the scrolling. With some optimizing, even simply drawing a single tile at a time per pixel scrolled you can get smoother results, even on a bog standard a500/a600. You can also skip rendering a tile when the area of graphics is blank, which with something like Mario can be upwards of 1/3rd of the time.

Check out final fight aga as a recent blitz example, or a brief bit of my half finished "Dragon's Lair AGA" port:
[ Show youtube player ]

By the way, Reality is a piece of crap
If you think its quality then we clearly have different ideas of the definition of the word "quality".
It screams, "look at me, I'm made with AMOS"

[Samurai_Crow]

AmosPro has a bad compiler but the programming environment is quite handy. As for the tile scrolling, I'll work on that also with the TOME replacement I'm going to work on once I have written Tilemap.library in C.

[idrougge]

Originally Posted by ReadOnlyCat

As Mrs Beanbag pointed with her usual reasonableness, there is close to no conceptual difference between gosub and a function call (especially if you do not pass parameters) so the only explanation for Blitz Basic behaviour is well... that it is likely very ill conceived.

Possibly. The source code is available and still updated in the shape of AmiBlitz, so whoever can read "the ugliest assembly code ever written" is free to find out what Blitz does wrong.

Originally Posted by ReadOnlyCat

I wish there was an IDE on the Amiga configurable enough to work straight out of the box with external languages (AmigaE, C, Arexx, etc.) because I'm fairly convinced that the reason AMOS and BlitzBasic still have so many adepts is that they provide an integrated development environment which helps non-experts feel secure enough which in turns allows them to experiment.

Don't we all?
Only, Blitz coders have wished since 1992 that the environment was a bit less integrated, since the compiler is tied to the abysmal Ted editor. It's not as bad as Emacs or Vi, but it's still a shitty editor.
AMOS, on the other hand, has an integrated environment that looks good to this day.

[ReadOnlyCat]

Originally Posted by idrougge

Possibly. The source code is available and still updated in the shape of AmiBlitz, so whoever can read "the ugliest assembly code ever written" is free to find out what Blitz does wrong.

Oh, I was really out of the woods for too long, I did not know the source was available. And no, I won't be touching it with a ten meters pole.

Originally Posted by idrougge

Don't we all?
Only, Blitz coders have wished since 1992 that the environment was a bit less integrated, since the compiler is tied to the abysmal Ted editor. It's not as bad as Emacs or Vi, but it's still a shitty editor.
AMOS, on the other hand, has an integrated environment that looks good to this day.

Well, I quite like Emacs! Even though I use SublimeText these days to edit my personal code.

While we are talking about IDEs and Amiga development, I must mention again to any wannabee Amiga coder the great Toolchain that Hannibal from Lemon did on Windows:
http://www.pouet.net/prod.php?which=65625 (click the download link on the right).

It works with Visual Studio and the included examples allow to create a boot demo and launch it as a boot disk inside WinUAE with the press of a key. Reaaaaaally neat.

It is still a bit terse for a complete noob but for any experienced coders it should be a god send. If someone decided to make tutorial videos with it maybe we would have a chance to dissuade people from using Amos or Blitz.
(It uses vbcc and vasm so it supports C and assembly straight out of the box.)

Originally Posted by beezle

Gloom and Skid marks are good examples, even if they do use some inline asm.

Ah! I had forgotten Skid Marks was written using Blitz, thanks for pointing it out. It's an example of a fantastic game made with the language indeed but even a few example do not make a trend.
I persist in thinking that you have to be a good programmer in the first place to make anything good in Blitz, because as a novice you will not have enough background to understand where and why it is innefficient nor work around it without compromising your program's structure.

Originally Posted by beezle

Why more software wasn't produced with it is probably more to do with portability and paradigms than capabilities.

This is very possible, my point is that newcomers should avoid Blitz if they want to acquire good coding habits and grow as coders. As you said it, the language as a proven track record of allowing great programs to be conceived but that does not mean it is suited to the EAB roaming bunnies who want to learn what code is all about and try to make their own games.

(This said, I must also say I am not convinced that C would be the best starting language for a new coder but I still think it's better than a BASIC.)

[Mrs Beanbag]

i really would prefer to be able to use a text editor of my choice to write programs for the language of my choice, Devpac's editor is fairly good i use that for everything texty these days (on Amiga).

I would like C++ on Amiga but apparently it is quite resource-heavy? not sure why

[Megol]

Originally Posted by idrougge

Well, so was I, but I'm not convinced that other languages have function calls for free.

Well... Forth can get very close to free as functions are comparable to gosub statements. OTOH most Forth systems aren't using compilers and emulating a stack architecture on a register machine have some overheads. OTTH (don't we all have a third hand? ;P) a good Forth interpreter can be competitive with a bad compiler for some normal languages.

Edit: Here bad compiler = for example a compiler targeting a register machine that uses a stack based model and a pattern matching code generator.

Originally Posted by Dunny

How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.

That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.

I guess we are talking about BASIC compilers? Otherwise e.g. VBCC seems to optimize well in my limited experience.

[Mrs Beanbag]

putting a few local variables and/or parameters on the stack really shouldn't be a big deal anyway, but my plan is to include with my compiler an option to output as ASM source so you can optimise manually at will.

[Samurai_Crow]

Originally Posted by Mrs Beanbag

i really would prefer to be able to use a text editor of my choice to write programs for the language of my choice, Devpac's editor is fairly good i use that for everything texty these days (on Amiga).

I would like C++ on Amiga but apparently it is quite resource-heavy? not sure why

The meta-programming capabilities of deeply nested templates will quickly exhaust the meager amount of memory of a 68k Amiga, even fully expanded. I was hopeful that ChrisH would get type-safe macros (comparable to generics) and other stuff implemented in PortablE using only a C compiler as a backend. He seems to have lost some momentum as of late though.

Originally Posted by Megol

Well... Forth can get very close to free as functions are comparable to gosub statements. OTOH most Forth systems aren't using compilers and emulating a stack architecture on a register machine have some overheads. OTTH (don't we all have a third hand? ;P) a good Forth interpreter can be competitive with a bad compiler for some normal languages.

Edit: Here bad compiler = for example a compiler targeting a register machine that uses a stack based model and a pattern matching code generator.



I guess we are talking about BASIC compilers? Otherwise e.g. VBCC seems to optimize well in my limited experience.

Early implementations of LLVM had a Forth-like language called "Stacker" bundled with it but its author moved on and it quickly became unmaintained. There is a 68k backend in the works but the ones working on it have other concerns right now. The optimizer for the LLVM intermediate representation is nearly exhaustive in its implementation.

Still, though heavy, LLVM can be made more modular than other compilers due to its library-based design. It's a matter of making all the libraries not load in until they are needed and unload when they are done (though the first step is making a cross-compiler from an already-supported OS). Thus it is possible to make it run under AROS using its OOP.library (included in the kernel) to implement the C++ runtimes known collectively as LibC++. I'm afraid it will be a bit much for OS3 to chew on though, unless some hybrid emerges like AfaOS incorporates the absent features of any full version of AROS. It seems there's plenty to do and few people to do it.