WriteF('x is now \d\n', x:=1+(y:=(z:=fred(3,5)/2)*8)) ... I'm clueless. Is it an equation? Is it an assignment?? Is it printing a line???
Again, you are picking a very complex statement. AmigaE (and many other languages) allow you to make assigments AS PART OF an expression. You can rewrite it like this, and it means exactly the same:
z:=fred(3,5)/2 y:=(z)*8 x:=1+(y) WriteF('x is now \d\n', x)
So just to be completely clear, x:=123 assigns the value 123 to the variable x, **but** the assigment also has the value 123, and so it can be used as part of a larger expression. The only reason for doing so is to make things more compact, while making it less readable, therefore I hardly ever do anything like that myself.
Proc writeF(string: ARRAY OF CHAR, param1=0, param2=0) IS Print (string, pram1, param2) BUT PrintFlush() ... writeF I think is write to a disk file,
No, in AmigaE "WriteF" is (almost) the same as "PrintF". Both are used to print something that the user can see. Since I personally feel that this is more complex than needed, in PortablE I removed them & replaced them both with just plain old "Print".
The above of the above code is to show how the user can implement "WriteF" if they really miss it (note that WriteF & PrintF *are* provided by the AmigaE compatibility mode of PortablE). The "BUT PrintFlush()" bit can be ignored, but it's purpose is to make "writeF" behave exactly like it did in AmigaE.
Quote:
but everything else is ununderstandable. In fact, it's just assumed that I should somehow know what this does.
PortablE's manual is aimed at existing AmigaE users, because trying to cater to new users would be too much work for me at the moment. This is why the beginning of the manual says:
Quote:
2.1. What is AmigaE?
This manual is aimed at existing AmigaE users, as it mainly describes the differences between PortablE & AmigaE. Someone with no prior experience of the E language should first become familiar with AmigaE. ... Jason Hulance's great beginners guide: http://cshandley.co.uk/JasonHulance/beginner_1.html
For instance on page 25. ----- start if test WHILE foo() = FALSE test := bar() ENDWHILE IF test = NIL ENDIF ----- end WHATEVER (very very clueless as to what it achieves, or how it works) the above means, I'm sure I could code the identical ALOT easier in Basic.
Again, this is an example which doesn't do anything meaningful, so it is perhaps not surprising that you find it difficult to understand.
Also, it was actually INTENDED to be a complex example, so I will not discuss it further here.
Makes sense to me. Heck, it's even a complete computer program. That ONE line. Does practically nothing, but it's EASY to understand. Why is this against the "Coder's Law"??? While C and PortablE and most of the other languages have oodles of overhead involved in such a simple construct as asking that a toke becomes some group of 8 bit characters.
This seems to be your sticking point. It is also your misunderstanding. The "oodles of overhead" are either:
(a) because the language allows you to do more & allows your programs to grow beyond toy examples, or
(b) in some cases because the language is 'lower level', and therefore you need to do more work to achieve the same thing, but as a result the language is not doing wasteful stuff that you don't need either (so it is faster).
BTW, if "A$" will never change, then you can do this in PortablE:
If you want to program a game without learning a lot about Amiga Internals, a game that works on all platforms (execpet AROS) and is fast, you probably want to use Amiblitz3. (hey, it is NOT an old-tool and NOT hardware banging)
It provides the flexibility, ease of use and speed you need for a game. The only alternative I see would be Hollywood, but I dont know enough about it to recommend or not-recommend it.
However, from a Programmers point of view, C is quite a nice language and not hard to learn at all. It is much harder to kearn the AmigaOS API, which you must do in every language that does not provide fancy commands like image_Blit, image_Load for you. Amiblitz3 gives you both possibilities.
I don?t agree, and I don?t like how E uses () where C uses []
I think you're mixed-up, since E uses [] in the same way that C does. Anyway, the other stuff you mentioned is probably just personal preference, and not worth arguing over.
I code for OS4.x as a baseline, because I can use all the nice new functions in the later release, and make use of all those BOOPSI classes that only do what I want under 4.x. To be able to make my applications run under 3.x would mean seriously downgrading functionality in order to support it.
If people knew which functions are causing the main incompatibility, one could update OS 3.x .
Quote:
So, do I cripple my software in order to keep a level of compatibility which, to me, is a waste of time, or do I continue to look forward and make use of everything available to me?
Depends if you are happy with keeping all your eggs in one basket.
4. awk.lha ? awk the text processing language Huh??? Requires ABCshell to work. Great for documents and dictionaries. 12. perl.tar.bz2 ? Perl 5.8.5 AmigaOS4 Andy Broadband done a nice job of bringing PERL to OS4.0. Required for 'Frozen Bubble' game. 19. sdlbasic.lha ? SDL Basic Just doesn't work. It works perfectly and very powerful. The best basic for OS4 yet. I wrote 'DealNoDeal' with it. Ask the 'Swan'.
@LiveForIt ...your wasting your time whit Basic, go and learn C ... I disagree. The system should use C, not the average user. I find SDLBasic very useful for problem solving persononal usage. AmiBlitz is maybe the best basic launuage you can get that will work on AmigaoS4.x I disagree again. SDLBasic wins hands down. Then again, how many people use basic to do anything on their Amiga?
Although if you have not declared "number" before, then you need to put this at the start of your procedure:
DEF number
@athiest Now, you might say, "why do I have to write DEF number before I can use number as a variable? This is annoying oodles of OVERHEAD!" The answer is that this provides additional protection against stupid mistakes, which in a big program can be very hard to find. For example, imagine you accidentally wrote this:
nunber := 5
The AMOS equivalent would not complain, and instead would store the value 5 in the wrong variable, and later (maybe much later) the program would do the wrong thing, leading to a long time debugging. But E (or C) would complain as soon as you tried to compile the program. This is the main reason why you have to declare variables before using them. Smaller benefits are:
1. It is forcing you to "document" your code as to which variables you are using, rather than relying on you adding comments, or remembering (which you likely will not in 6 months).
2. It allows you to specify the type of the variable once, rather than having to specify it EVERY time you use it. For example, in AMOS you would have to refer to a variable called mystring as mystring$, because otherwise it has no way of knowing that it is a string. But in PortablE you just write this once:
DEF mystring:STRING
And after that "mystring" is known to be a string, without any magic $ or anything. A *BIG* benefit of this is that E can have many more types than AMOS, which (IIRC) is limited to Integers, Floating Point & Strings.
If you are asking people who have invested time in writing something intended to be for OS4 only, that is the reply you will get. If you write for OS4, there are newer functions which can do resource tracking etc, and also other functions which make things easier.
Basically, if it has already been written with the intention of running on OS4 only, you end up having to rewrite bits of it for OS3. This can be a lot more work than you think.
I understand that if developers are determined in making OS4 only apps, nothing can be done about that.
With regard to your 2nd statement, thats the issue that bothers me. Why does it HAVE to be that hard in the first place, is there no easier way ?
Cant a smart IDE detect OS 3 compatibility setting and switch/replace certain functions with OS 3.x ones ?
----- start WriteF('x is now \d\n', x:=1+(y:=(z:=fred(3,5)/2)*8)) ----- end
I'm clueless. Is it an equation? Is it an assignment?? Is it printing a line???
As someone who has never used E before, this still makes sense to me. The example above is a print statement, an equation, and an assignment (in fact, multiple variables are assigned values in this). The code examples you used are NOT for beginners to the language.
You seem to think that you should understand everything immediately. That would be like expecting to be able to read music score immediately. The first time you look at music score, it looks like a bunch of lines and blobs. Over time, you learn what those lines and blobs mean.
There is nothing wrong or cryptic with 'C' or 'E'. You just need to be prepared to learn. Basic/Amos looks "intuitive" to you because you're used to it, but it is actually a poor programming language when compared to modern ones.
You need to stop expecting to somehow magically understand it immediately, and take the time to learn. Enrol in a programming course that teaches C; buy a book on C; be willing to learn.
As for Python, there is a PyGame module but I don't know if it is possible to use it on OS4 A lot of python programs require 'modules' which need to be compiled for OS4. I haven't found info on how to do that yet. In other words, we don't have the compiler module to compile modules! ...it doesn't appear to offer any advantages over the language it is trying to replace, yet manages to look much more complicated. Forth was my first compiler language. I see a lot of similarity with Python and Forth. Script syntax can the hardest problem of any language. So far, SDLBasic and Python are the best user tools in Amiga right now for me. Oh yes, I need ABCshell too.
t's easy to write code that runs on any 68K or PPC machine (OS4 or MOS), you just have to use the old APIs. But if you are an OS4 or MOS developer, you'll probably use some of the bells and whistles that your favourite OS provides, making it difficult to port.
If you consider that a problem, it's the fault of the author, not the OS.
Yes you want to use all the bells and whistles, writing compatible code is down to the author.
Thank you, thats how I understand it. I didnt say it would be easy, far from it.
My want one common library that detects different AmigaOS and just run the code for that system instead of each Amiga variation having a different one. One Make file to compile the binary.
I use Cubic IDE on OS 4.x, and it works fine. There is an IDE in the works.
Its good to know an IDE is in the works. Is it OS4 only ?
Quote:
I don't think that we need a dev package that supports all Amiga OS variants in order for it to become popular again. OS3 hardware doesn't have the necessary CPU power for any of the stuff that I'm involved in, and the other systems all use GCC and are similar enough that you could write cross-platform software if you wished.
While new hardware is slow to come by, and machines failing, Amikit/Winuae is the only option, yet being OS3 based, the challenge of incompatible software is increasing.
Quote:
What I think would make it popular again is having modern functionality, and software libraries that make writing/porting software easier to do. Much progress has been made in this area, but we're still lagging behind in the 3D graphics department (amongst other areas).
I am glad to agree with you. There are not enough developers, and enough problems in Amiga land, lets try make porting / compatibility problems not one of them.
Yes much progress has been made for compatibility, my thanks go to all developers in their efforts.
What do you mean by "GFX/SND portability"? AmigaOS support of these should be the same. Not to mention that E has commands like Plot() for drawing graphics to windows.
I mean a single opensource driver for RTG gfx and sound for all Amiga /Amiga compatibles. One codebase, optimised for each system.
You need to stop expecting to somehow magically understand it immediately, and take the time to learn
Thats his problem. He expects to know how to use a language without learning it first. It's so stupid. I give up. No more advice from me ever. He's a lost cause.
ChrisH wrote: That is actually incorrect, a lot of Amiga games were written in BlitzBasic, a few of them even commercial. e.g. (Super) SkidMarks, and Zombie something-or-other. I think the first Worms (or at least it's prototype) was done in AMOS?
Worms, WormsDC and Worms CD32 were all written completely using Blitz. Not just the prototypes/early demos, but all the commercial released for the Amiga. Gloom (the Doom clone) was Blitz too, as were all the Skidmarks games. I'm sure there are plenty others, just can't think of them for now.
Blitz - especially in its current form of AmiBlitz3 - is a very capable language. It fully supports using commands like Blit shape, Playsound etc. for easy use of objects loaded from disk - though this way of doing things is generally slow. Thanks to the ongoing work of Wanderer and all those guys though, it also supports doing things the "real" way, i.e. using structs, pointers and OS calls. It really does take the best of both worlds and put them in the same place.
@OP I dunno. It sounds to me like you're not looking for a programming language, but more for a construction kit. There were some of these years ago, where you wrote simple scripts and tied them to objects/actions - maybe they're still around somewhere? Personally I found them way too restrictive...
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
