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

[daxb]

Originally Posted by Samurai_Crow

The fact that tabs OR spaces but not both can be used with Python is a terrible annoyance, indeed. I still lean in favor of a graphical tree gadget though.

I remember that (more then 10 years ago) the teacher used Python as language for the course. The thing with tab/space and indent was very annoying. Trying to hunt the invisible error. I just thought how stupid is that.

[Mrs Beanbag]

try makefiles...
a line indented by spaces, and a line indented by tabs, mean different things

[Samurai_Crow]

Originally Posted by Samurai_Crow

Back on topic. To make homebrew games easier to write and such, Mike Parent is starting a series of bounties for AmosPro programmers. If accepted, I'll be doing my part by making a shared library for tilemap manipulations that can be used by any 68k language that supports shared libraries. The library itself will be written in C but support will be extended to AmosPro and AmigaE as well. It will be based on the example codes by Georg Steger found in http://aminet.net/package/dev/src/ScrollingTrick.

@thread

I've posted on UltimateAmiga.co.uk about my plan to make a gaming library. There are a lot of independent stretch goals once the main objective is met. See the post here and see the milestones available here. Toss a coin into the hat on https://www.bountysource.com/ and I'll find the time to do it faster!

[Retro1234]

Originally Posted by Samurai_Crow

@thread

I've posted on UltimateAmiga.co.uk about my plan to make a gaming library. There are a lot of independent stretch goals once the main objective is met. See the post here and see the milestones available here. Toss a coin into the hat on https://www.bountysource.com/ and I'll find the time to do it faster!

I would never ever use this - why don't you just write it in Amos instead of trying to port this AmigaE example or what ever it is? Sorry to seem hostile but you go on about this AmigaE example - write it yourself!

[Samurai_Crow]

ScrollingTrick was written in C as example code. It was never designed to be reusable. (In fact, I couldn't write it in AmigaE no matter how hard I tried because the library mode is broken beyond repair in the compiler.)

Why am I doing this in C? It compiles better than AmosPro, supports inline Assembly better than AmosPro and most importantly, can bang the hardware without having to disable all the high-level features of AmosPro and litter my code with Exec library calls and wierd banks whose only purpose is to emulate structure functions that are natively supported in C.

Why as a shared library? It can be used from any language you choose, as many times in the same code as you choose. Many languages (including Assembly and AmigaE) have utilities for importing shared library support from the FD file (FD2Pragma for example). But best of all, just by swapping the shared library for one written for graphics cards, you instantly have graphics card support without even trying!

[Retro1234]

Ok its not good to poo poo Amiga projects so good luck, Its not for me and I think your take some of the Fun away thats why I get a bit worked up.

[Mrs Beanbag]

i don't know how it takes any fun away, to provide the sort of high-level functionality that AMOS provides to other languages

[Retro1234]

I think the bounty is to add wrap around and some other stuff to Amos and other languages.
I think once you start doing this your just end up with command line backbone in theory this is ok but games might not have individuality.
But like I say I shouldnt knock it.

[Mrs Beanbag]

well we already get a lot of backbone games anyway, unfortunately backbone is very slow and clunky, so it could only be an improvement there.

but i thought the point was to provide such basic things as scrolling playfields, a bob engine, music playroutines and sound effect engine &c..

you'd still need to program the actual game itself.

[Dunny]

Originally Posted by Mrs Beanbag

Procedure calls are apparently very costly, don't ask me why

It's because the parameters have to be placed somewhere before the procedure is called. Commonly, your compiler/interpreter will set up a stack in memory which has enough space for the values you're passing, then write them in (at runtime, regardless of whether or not you're using a compiler or interpreter) and then issue a call to the procedure, which has been compiled to pull its parameters from the stack. Even parameters passed by reference have their pointer values stacked and then re-read out during the procedure.

Modern compilers will of course store parameters in registers where available before touching the stack, but I'm not sure how often that sort of thing was done back in the day - it's quite an old method.

There are also other methods available now with these days of large CPU caches to mitigate this speed penalty, but for things like AMOS they couldn't be taken advantage of.

D.

[Mrs Beanbag]

yeah yeah fair enough i do know how function calls work at the low level, but pushing a couple of 32 bit integers on the stack really doesn't account for how slow AMOS's procedure calls are, there must be something else going on there.

[clebin]

Originally Posted by Samurai_Crow

ScrollingTrick was written in C as example code. It was never designed to be reusable. (In fact, I couldn't write it in AmigaE no matter how hard I tried because the library mode is broken beyond repair in the compiler.)

Why am I doing this in C? It compiles better than AmosPro, supports inline Assembly better than AmosPro and most importantly, can bang the hardware without having to disable all the high-level features of AmosPro and litter my code with Exec library calls and wierd banks whose only purpose is to emulate structure functions that are natively supported in C.

Why as a shared library? It can be used from any language you choose, as many times in the same code as you choose. Many languages (including Assembly and AmigaE) have utilities for importing shared library support from the FD file (FD2Pragma for example). But best of all, just by swapping the shared library for one written for graphics cards, you instantly have graphics card support without even trying!

This sounds like exactly what I've been looking for - thanks so much!

@Boo Boo: Whatever you say, the Amiga development scene needs this boost. At the moment, there is no pathway for someone to easily get into Amiga programming and master the hardware at their own pace.

AMOS is slow and a dead-end in terms of learning; Blitz teaches some concepts about Amiga hardware but is still a dead-end (as well as doing its best to alienate everyone with its IDE). The only thing left is learning low-level hardware tricks from scratch. That's a big ask if you're short on time.

I hope I've got this wrong, but you seem to like the fact that learning Amiga programming is made as difficult as possible, with no leg-ups, no means of learning while having fun - just a hard slog where everyone has to learn to reinvent the wheel.

[Retro1234]

I have no real preference for language - I dont see basic as a dead language if anything its coming back but thats not the point. I have no problems with C,E or Asm whatever. What im saying is have a bit of pride and write the routines yourself - Like the old school demo scene or the guys working on Rygar.
Amos often gets the blame for peoples shortcomings is this not half the problem - people will still complain I need more done for me.

[Dunny]

Originally Posted by Mrs Beanbag

yeah yeah fair enough i do know how function calls work at the low level, but pushing a couple of 32 bit integers on the stack really doesn't account for how slow AMOS's procedure calls are, there must be something else going on there.

Most likely it's extending the variables area, assigning variable names into that area (string writes per variable) and then the variable values so that the procedure just has to use them like any other variables in the list. That would be a lot slower than just writing an integer to a memory location - and of course, exiting the procedure means having to destroy those variables and reclaim the RAM they occupied...

That's just speculation though; I've not read the Amos source code.

D.

[Megol]

Originally Posted by Mrs Beanbag

the advantage is that you can always tell there is a block there, basically "do...end" is equivalent to "{...}" but with friendlier symbols. Another idea that just occurred to me, is to use a colon for the long form and a comma for the short form. This is a bit like how we'd use punctuation in English:

if n=0, return 1
-- or
if n=0:
   return 1
end

Python uses a colon to start a block and IMHO that is a problem. I want the language to be readable in a plain editor on a high resolution screen without color coding and then a colon combined with other characters can be hard to see. Making a control statement the start of a block also reduces typing.

unusual if syntax, btw.. it appears to actually reverse the order in which the terms would be executed

I guess you mean the selection syntax? Guarded statements aren't that unusual and should be easy to understand - they do exactly what they spell out.

print "Hello world!" if user.state=available

if(user.state==available) print("Hello world!"); // C languages

The selection syntax is actually an accident and preliminary but I'm actually starting to like it. It is also easy to read and can reuse some parts of the guarded statement parser. IIRC the syntax used in Python too.

name:="BASIC" if user.level=beginner else "C++" 

name=(user.level==beginner)? "BASIC" : "C++"; // C languages

IMO it should be easier to read even for beginners. YMMV.

[Retro1234]

Originally Posted by Boo Boo

I have no real preference for language - I dont see basic as a dead language if anything its coming back but thats not the point. I have no problems with C,E or Asm whatever. What im saying is have a bit of pride and write the routines yourself - Like the old school demo scene or the guys working on Rygar.
Amos often gets the blame for peoples shortcomings is this not half the problem - people will still complain I need more done for me.

Then again Im not having to write routines to load Raw graphics etc I just dont know where you draw the line.

[ReadOnlyCat]

Originally Posted by Boo Boo

I think the bounty is to add wrap around and some other stuff to Amos and other languages.
I think once you start doing this your just end up with command line backbone in theory this is ok but games might not have individuality.
But like I say I shouldnt knock it.

A set of libraries does not constrain you, it provides additional capabilities that you are free to use or not use. BackBone on the other hand forces you in doing things a particular way.

Libraries just abstract part of the work needed to make a game and how you compose them is up to you.
Frameworks impose you a particular philosophy of game creation and design.

These are two very different creatures.

The alternative to using libraries is to rewrite all code from scratch every time. Libraries just gather useful functions together in a coherent set so that previous work does not need to be re-done.

I say let's all hug Samurai Crow!

[beezle]

Even c and asm use existing libraries.
This is more inline with Samurai_crows project. Its not really much different than SDL, opengl, etc. (Only I suspect less of a fully fledged api).
Different kettle of fish to something like backbone.

As Mrs. Beanbag said, you still have to code it yourself.

As for blitz, well, fewer restrictions there as it let's a user use existing APIs.... Cgx, p96, ahi, SDL, opengl,.... whatever.

edit: seems ReadOnlyCat beat me to it by a matter of seconds
edit2: despite continuing to join in the convo. I still think the last few pages warrant a separate thread

[Retro1234]

I doubt we will see this but I've been an amigan a long time and heard all this before. But you take away the collision and scrolling your not writing the game yourself realy.I don't care about language or libs etc - The goal is to take away everything

[beezle]

I don't really understand your last post, and this is over-simplifying things a little because thus far it seems you don't understand, but where do you think commands come from?
They come from functions in libraries.

Even in Amos.