English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 25 August 2015, 16:31   #321
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,927
Quote:
Originally Posted by Samurai_Crow View Post
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.
daxb is offline  
AdSense AdSense  
Old 25 August 2015, 16:33   #322
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
try makefiles...
a line indented by spaces, and a line indented by tabs, mean different things
Mrs Beanbag is offline  
Old 25 August 2015, 16:53   #323
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 989
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Samurai_Crow View Post
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!
Samurai_Crow is offline  
Old 25 August 2015, 16:58   #324
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
Quote:
Originally Posted by Samurai_Crow View Post
@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!
Retro1234 is offline  
Old 25 August 2015, 17:10   #325
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 989
Send a message via Yahoo to 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!
Samurai_Crow is offline  
Old 25 August 2015, 17:50   #326
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
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.
Retro1234 is offline  
Old 25 August 2015, 17:53   #327
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
i don't know how it takes any fun away, to provide the sort of high-level functionality that AMOS provides to other languages
Mrs Beanbag is offline  
Old 25 August 2015, 17:58   #328
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
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.
Retro1234 is offline  
Old 25 August 2015, 18:07   #329
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 25 August 2015, 18:21   #330
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 980
Quote:
Originally Posted by Mrs Beanbag View Post
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.
Dunny is offline  
Old 25 August 2015, 18:25   #331
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 25 August 2015, 19:11   #332
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 270
Quote:
Originally Posted by Samurai_Crow View Post
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.
clebin is offline  
Old 25 August 2015, 19:17   #333
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
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.

Last edited by Retro1234; 25 August 2015 at 19:26.
Retro1234 is offline  
Old 25 August 2015, 19:31   #334
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 980
Quote:
Originally Posted by Mrs Beanbag View Post
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.
Dunny is offline  
Old 25 August 2015, 19:33   #335
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 294
Quote:
Originally Posted by Mrs Beanbag View Post
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:

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

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

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

Code:
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.
Megol is offline  
Old 25 August 2015, 19:39   #336
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
Quote:
Originally Posted by Boo Boo View Post
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.
Retro1234 is offline  
Old 25 August 2015, 19:55   #337
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,026
Quote:
Originally Posted by Boo Boo View Post
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!
ReadOnlyCat is offline  
Old 25 August 2015, 20:01   #338
beezle
Banned

 
Join Date: May 2015
Location: Australia
Posts: 67
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

Last edited by beezle; 25 August 2015 at 20:07.
beezle is offline  
Old 25 August 2015, 20:08   #339
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,872
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

Last edited by Retro1234; 25 August 2015 at 20:15.
Retro1234 is offline  
Old 25 August 2015, 20:54   #340
beezle
Banned

 
Join Date: May 2015
Location: Australia
Posts: 67
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.
beezle is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the technically most impressive A500 game? mc68060 Amiga scene 67 03 June 2015 22:32
The Tales of Grupp - Another impressive homebrew ZX Spectrum title! Neil79 Retrogaming General Discussion 3 24 February 2015 19:19
New One Of "Homebrew" 68k Amiga Magazine Idea fishyfish Retrogaming General Discussion 6 16 April 2013 08:57
Impressive and Amazing PD Software! Any thoughts? hamster Retrogaming General Discussion 0 18 July 2004 01:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09176 seconds with 13 queries