Here is the fifth example of the next release of PortablE:
Example 5: SOTBScroll.e

This is a pretty "Shadow Of The Beast's" like scroller.  It is based upon a DarkBASIC demo by Frederic Cordier, with music taken from the AmiDARK version.  However, I was able to drastically simplify the code thanks to PortablE's "wrapped sprites".  Wrapped sprites make parallax scrolling (& scrolling backgrounds in general) very easy to do - no need for complex & error prone maths.

I have also included the source code for the original DarkBASIC demo, and a direct "NoSprites" PortablE port of that.


Further examples will be forthcoming! And don't forget the earlier examples:
Example 1: ShootEmUp.e
Example 2: SimpleModPlayer.e
Example 3: ToySpaceshipSprite1.e
Example 4: ToySpaceshipSprite2.e

Please note that examples with music need the ptplay.library installed.  You can get it from here:
aminet.net/package/util/libs/ptplaylib_os4 (OS4)
aminet.net/package/mus/play/PTPlayLibrary (OS3 & MOS)


As a reminder:

I have released a "full preview" of the next version of the PortablE programming language. It is now aimed at beginners & those new to the E language. Previous releases of PortablE were aimed at existing AmigaE users, and those familiar with AmigaOS programming. But after more than a year of development, PortablE is much easier for beginners to pick-up & play with:

* It now comes with some nice modules for graphics, sound, music & GUIs. These require no knowledge of AmigaOS programming, and were inspired by the simplicity of BASIC languages like AMOS.

* It comes with full documentation for all of these modules, along with smaller & bigger examples. The preview release does not include these examples, but instead I will be show-casing one of these examples every few days.

* The documentation has been revamped to be more beginner friendly, and the PortablE installer has been made easier to use. If you still get stuck, then let me know, and I will see what I can do


* In addition to that, I have made available a large collection of my own useful modules (in the CSH folder), which you can use if you want. These are not properly documented yet, but I will look at documenting them where there is interest.

* There are also various other improvements, and a lot of bug fixes.

* As usual it supports Amiga OS4, OS3, AROS, MorphOS & Windows. However (1) the new graphics module does not yet work on Amiga OS3, (2) the new modules do not yet work on Windows, and (3) MorphOS support is still experimental.


You can download it from PortablE's home page.

Last edited by ChrisH on 24-Feb-2011 at 11:40 PM.
Last edited by ChrisH on 17-Feb-2011 at 12:03 PM.
Last edited by ChrisH on 17-Feb-2011 at 11:56 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Cool but what about a Mac OS X port and why not supporting Iphone and Ipad too :)

Regards
Kamel

@kamelito Quote:

Cool but what about a Mac OS X port and why not supporting Iphone and Ipad too :)

Not sure if you are serious :) but I doubt OS X or iPhone any time soon. Possibly Linux or (better support for) Windows eventually. Maybe even Android, since as that is likely to be my next phone.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

I'm serious about OSX, as Iphone and Ipad are based on OSX is shouldn't be difficult to make it run there too.
Check Iptk it support both systems.
http://code.google.com/p/iptk/

Did you plan to follow Wouter to do list ? (http://cshandley.co.uk/amigae/ch_18e.html)

Kamel

Last edited by kamelito on 17-Feb-2011 at 09:22 PM.

@kamelito Quote:

Did you plan to follow Wouter to do list ? (http://cshandley.co.uk/amigae/ch_18e.html)

That appears to be mostly AmigaE-specific bugs, and as such nothing to do with PortablE (since it is written from scratch). For the "Future Todo's", quite a few of those are compiler-related, and so irrelevant given that PortablE uses GCC to do the actual compiling. There were a few points which could have relevance to PortablE:

* "extend CONST expressions with floats etc". It is very unlikely that floating-point constants will be supported (due to how PortablE is implemented), but you can use #define to work-around this limitation. However, PortablE *does* already support "constant-like" strings & lists using the STATIC keyword, and maybe Wouter was thinking of that for "etc".

* "improve error reporting" was one of my aims for PortablE, so it already has this

* "class variables". E already has the "self" class variable, not sure what others could usefully be added. I had considered a "super" class variable, to replace "SUPER self", but not a priority as it doesn't improve functionality, just make things a little shorter.

* "short-circuit AND / OR" does not much make sense IMHO, due to how E works. At best this would make certain code slightly more compact, but you could achieve the same using some simple procedures.


For "Wild Ideas (aka Big Todo's)":

* "plug a general back-end onto EC (to allow for code generation to other cpus (e.g. PPC) or even languages (e.g. C) or better optimizers etc.)" PortablE has something very close to this!

* "extend the language with lambda's / higher order functions / lazyness etc." & "concurrency system based on Linda". Very unlikely to happen in general, as I already removed AmigaE's extremely esoteric (and very underused) Lisp/etc kind of functionality.

Also, not sure exactly how AmigaE would have been extended to specifically support "higher order functions", since it already supported function pointers. PortablE has a type-checked form of function pointers (using FUNC instead of PROC), and that pretty easily allows "higher order functions" to be written (which is just a fancy name for a function which takes or returns another function).

* "better debugging / analysis / type inference tools". Not sure what he was thinking of here, but improved debugging tools is always a possibility.

* "full visual language on top of E". While this may have been a passion of Wouter's, I'm not sure it makes a lot of sense, and would mostly be of only academic interest. Not going to happen for PortablE anyway, but no main-stream language does it either. (It's possible that Wouter was very ahead of everyone else, and in 20-30 years time this will be popular!)

Last edited by ChrisH on 18-Feb-2011 at 10:35 AM.
Last edited by ChrisH on 18-Feb-2011 at 10:32 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

That's quite impressive how short and simple that example #5 is.

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@AlexC Quote:

That's quite impressive how short and simple that example #5 is.

Thanks although of course I can't take all the credit for the demo...

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

* "short-circuit AND / OR" does not much make sense IMHO, due to how E works. At best this would make certain code slightly more compact, but you could achieve the same using some simple procedures.

I'm pretty sure he means short circuit evaluation, which is an optimisation e.g. if the left side of an OR is true, there is no point evaluating the right side, likewise if the left side of an AND is false, there is no point in evaluating the right hand side.

One handy thing it enables you to do is avoid a null pointer reference neatly within a single expression, for example:

if ((pointer != NULL) && (*pointer == 1234))
{
printf("Pointer is 1234!\n");
}

If PortablE generates C code, it probably inherits this behaviour from GCC anyway.

Last edited by xeron on 18-Feb-2011 at 07:13 PM.

_________________
Playstation Network ID: xeron6

@ChrisH

interesting but..
I cant run it...I get:

cGfxWindow.loadPicture(); Hi/True-colour masks are not yet supported.
ERROR: Failed to load the picture "gfx/sprite_barriere.bmp".
EXCEPTION: " ERR"; Failed to load picture.

My mistake?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@xeron

Quote:

xeron wrote: @ChrisH Quote: * "short-circuit AND / OR" does not much make sense IMHO, due to how E works. At best this would make certain code slightly more compact, but you could achieve the same using some simple procedures. I'm pretty sure he means short circuit evaluation, which is an optimisation e.g. if the left side of an OR is true, there is no point evaluating the right side, likewise if the left side of an AND is false, there is no point in evaluating the right hand side. One handy thing it enables you to do is avoid a null pointer reference neatly within a single expression, for example: if ((pointer != NULL) && (*pointer == 1234)) { printf("Pointer is 1234!\n"); } If PortablE generates C code, it probably inherits this behaviour from GCC anyway.

Umm...
if (pointer != NULL)
if(*pointer==1234)
{
printf("Pointer is 1234!\n");
}

is just as pretty and has about the same number of symbols.

@Samurai_Crow

Quote:

Umm... if (pointer != NULL) if(*pointer==1234) { printf("Pointer is 1234!\n"); } is just as pretty and has about the same number of symbols.

And now try this:

if ((pointer) && (*pointer == 1234)) {
printf("Pointer is 1234!\n");
}
else {
printf("Error!\n");
}

Edit:

if (pointer ? (*pointer == 1234) : FALSE) {
printf("Pointer is 1234!\n");
}
else {
printf("Error!\n");
}

should work, but not as readable and it just gets worse if you need another &&..

Last edited by Returner on 18-Feb-2011 at 10:29 PM.

_________________
Selur erutangis siht

@xeron Quote:

I'm pretty sure he means short circuit evaluation, which is an optimisation e.g. if the left side of an OR is true, there is no point evaluating the right side, likewise if the left side of an AND is false, there is no point in evaluating the right hand side.

Ah yes, you are surely right.

Quote:

If PortablE generates C code, it probably inherits this behaviour from GCC anyway.

No, PortablE has the same behaviour as AmigaE, not C. This is because AND/OR/etc are bitwise rather than logical.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

HI, Your examples is good, please write an example with simple graphics like default examples clock.e and graphics.e but with mouse using - detection clicking and moving, reading coordinates etc. I need also example with mixing graphics and MUI in one window and some more mui examples with an action after clicking buttons.

@mrdarek Quote:

please write an example with simple graphics like default examples clock.e and graphics.e but with mouse using - detection clicking and moving, reading coordinates

I guess that a toy drawing program would cover that. I'll see what I can do (and feel free to bug me again if I forget!).

Quote:

I need also example with mixing graphics and MUI in one window and some more mui examples with an action after clicking buttons.

Do you really mean MUI (i.e. MODULE 'muimaster'), or do you mean my portable GUI system (MODULE 'std/cGui') which currently happens to use MUI?

And do you really mean in "one window"? Or two separate windows on the same screen?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

Do you really mean MUI (i.e. MODULE 'muimaster'), or do you mean my portable GUI system (MODULE 'std/cGui') which currently happens to use MUI?

I talking about mui folder with examples. All examples show different buttons, sliders, checks etc. but no example with buttons and graphics like lines, circles and simple text in one window. I need example window with button. If I click button circle appears (in this same window, or line or square etc) or any simple graphics action in that window...

Here is the sixth example of the next release of PortablE:
Example 6: SimpleCalculator.e
As more GUI examples have been requested, here is a simple calculator, in 112 lines of E code.  So that you could see the GUI code without too much klutter, I cheated a little:  The calculator only does integer maths (no floating point), which means that 3 divided by 2 equals 1 not 1.5 !  But it's not too much extra work if you want to add floating-point support...

Last edited by ChrisH on 24-Feb-2011 at 11:52 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

Here is the seventh example of the next release of PortablE:
Example 7: ToySketch.e
Someone wanted to know how to handle mouse input, so this example is a very simple drawing program, in 79 lines of E code.  (It could have been even smaller, but I got carried away adding features!)  I think you could have great fun expanding this into a fairly fully-featured drawing program... the only real draw back being that at the moment you won't be able to save the picture (I need to add a feature to the cGfx module to allow this - if you really want this then let me know & it might make it into the next Preview release!).

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

It was pointed out to me (again... doh) that the executables won't run on MorphOS, because they are missing the Executable flag. So I have fixed it for all examples.

If the examples didn't previously run on your MorphOS machine, please redownload & try again!

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Well, setting the flag manually isn't really a rocket science, I don't think anyone had a problem with that. It's just better when it's set by default, so we can just unpack and double-click.

@recedent Quote:

I don't think anyone had a problem with that.

Although I would agree with you, you never know what users will have a problem with! So I try my best to make things "just work" where possible.

EDIT: In fact I just saw DAX get stumped by another program not being executable, thus proving my point!

Last edited by ChrisH on 01-Mar-2011 at 11:31 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...