Here is the Eighth example of the next release of PortablE:
Example 8: StarsXY.e
This is the first of several pretty "stars" examples.  They are not so much examples of the graphics module as they are examples of  general PortablE code, and what can be achieved with a little bit of clever maths.

This example shows stars moving across the screen (in the X/Y plane), with depth parallax, in 87 lines of E code.  Although it is fairly well optimised, I have avoided a few obvious optimisations to keep the code clearer.

Last edited by ChrisH on 02-Mar-2011 at 11:41 PM.

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

@ChrisH

Under Windows I got

"ERROR: Could not find specified module
LINE 2: PUBLIC MODULE ##'target/std/cGfx'##"

Kamel

PS : I suppose that for windows / are replaced by \

@kamelito
I'm afraid that PortablE's new Graphics/Music/Sound modules are not YET supported for Windows. But I do plan to fix that though, once I am sure those new modules have "settled down".

However, you can still generate Amiga C++ code (using those modules) on Windows, and even (cross)compile them on Windows (using AmiDevCpp).

Quote:

PS : I suppose that for windows / are replaced by \

No, for compatibility module paths are always stated using / . They will automatically converted to the right format by PortablE (using the 'std/cPath' module).

Last edited by ChrisH on 03-Mar-2011 at 12:32 PM.

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

Here is the Ninth example of the next release of PortablE:
Example 9: StarsZ.e

After writing the first "stars" example, I got to wondering how a lowly A500 could manage to "zoom into" stars...  After some fiddling I came-up with an algorithm which has low memory & CPU usage, and only uses integer maths.  So it could quite plausibly be the same algorithm as used by some A500 demos (albiet in E not 68k assembler).

This example shows stars moving out of the screen (in the Z plane), in 92 lines of code.

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

Here is the Tenth example of the next release of PortablE:
Example 10: StarsZYX.e

Some A500 demos did more than just zooming straight into stars, they actually moved around inside them (in 3 dimensions).  After some thinking, I realised I could use a trick from StarsXY.e to do this with my StarsZ.e code.

This example shows stars moving out of the screen, while also moving across the screen, in 108 lines of E code.  It could however do any movement within the star field, by just changing how x/y/zOrigin are updated.

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

Here is the Eleventh example of the next release of PortablE:
Example 11: StarsDemo.e

OK, you are probably sick of "stars" examples now, so this is the last one... I promise!  After doing the rather demo-like StarsZYX.e example, I realised it wouldn't take much more to make it feel like a real demo or bootblock loader.  So what I did was add some demo-like music (very easy!), and a wavy text scroller (less easy but it was fun to work out how to do it).  It comes to 234 lines of E code.

NOTE:  The performance isn't as good as I'd hoped (I haven't had time to investigate why), so it needs to use frame skipping on my 667MHz Sam440.  As I had to disable frame skipping for MorphOS, this means it may run a bit slowly on something like an Efika.

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

@mrdarek
Sorry for the late reply.

Quote:

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

What's wrong with the following examples?

Class1.e, Class2.e, Class3.e & Subtask.e show drawing within the MUI window. Class3.e even shows arbitrary drawing (according to user input).

Envbrowser.e, Settings.e, ShowHide.e, Subtask.e & MUI-Demo.e have buttons which respond to being clicked. (Layout.e also does, but I just discovered it no-longer compiles...)


Note:
I discovered some problems with Layout.e & Slidorama.e, but they are now fixed for next preview release of PortablE.

Last edited by ChrisH on 08-Mar-2011 at 10:14 AM.
Last edited by ChrisH on 08-Mar-2011 at 10:11 AM.

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

@ChrisH

Chris thanks for your ongoing development of PortablE and all the benefits it brings to the Amiga platform.

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@ChrisH

My hero!

I have always loved the concept of AmigaE, but seeing some of those example sources really blew my mind. Haven't done any programming on the Amiga, seeing as how I have to do it for money all day long.

But man, you just made me want to start programming outside business hours

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil Quote:

seeing some of those example sources really blew my mind

In a good way, or a bad way? :D

Quote:

But man, you just made me want to start programming outside business hours

Cool!

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

I have uploaded a new PortablE preview. Most important is an improved installer, but the documentation also contains some small improvements.

The installer will now create a PEmodules folder, rather than assuming you have created one. The installation of the necessary C header files is now improved, also done for OS3 & MOS in addition to OS4.

Last edited by ChrisH on 09-Mar-2011 at 11:27 PM.
Last edited by ChrisH on 09-Mar-2011 at 11:25 PM.

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

@ChrisH

Chris, you may find this totally uninteresting, but as a language developer, you are particularly well suited to hear this thought. (Note: I've only begun to learn PortabLE, so I could be off base here). Anyway, here goes....

As I'm sure you are aware, a new bread of dynamic languages has been gaining momentum over the last 5 to 7 years. Particularly Ruby. Some would say Python, but Python is not as dynamic as Ruby.

IMO, Ruby is among the most evolved language designs in existence today and represents the biggest shift in "programmer thought" since OO. (Clojure, Groovy and Python deserve honorable mentions, but Ruby is still the king of dynamic language design). However, IMO Ruby suffers one very large setback:

... All errors must be caught at run-time ...

Such is the nature of a weakly-typed, interpreted language. But in my experience, this fact partly negates the advantages of the language. Hence what I've thinking about... in a nutshell, I think it would be very interesting to take an actively developing, compiled language, and emulate some of Ruby's advances and idioms, without the loss of type-safety and compile time error reporting.

To be able to capture the advantages of the latest dynamic languages, while retaining the virtues of a proven, compiled approach would be a first TMK. And such a language might strike a better balance between the latest thinking in language design and the latest thinking in OO, structured language and compiler design.

I know some of Ruby's idioms are enabled by it's typeless, interpreted approach. But many of them are not, or they could be scoped in such a way that all type-safety is not ejected. And to endow PortabLE with some of Ruby's tricks might make for a new breed of language that would potentially gain it a lot of attention. Reason being... dynamic and static languages have forked in a big way, and an attempt to merge the best ideas of both in a kind of re-convergence would be a thought provoking first IMO.

Anyway, just a thought...

Last edited by jingof on 11-Mar-2011 at 01:46 AM.
Last edited by jingof on 11-Mar-2011 at 01:45 AM.
Last edited by jingof on 11-Mar-2011 at 01:37 AM.
Last edited by jingof on 11-Mar-2011 at 01:37 AM.

_________________
Vic-20, C-64, C-128
Amiga 1000, 3000
AmigaOne X1000

@jingof
Yes, I am very much interest in language design. I am also interested in static vs dynamic trade-offs, but I am not really familiar with Ruby. There are a few people (such as the infamous Steve Yegge) who ARE interested in combining the best of static & dynamic languages, so something may well appear eventually.

I've debated myself about the best approach (start with a dynamic language & add optional static features VS start with a static language & add optional dynamic features), and came to the conclusion that you can't really modify an existing language & expect it to get much benefit. I think you need to start with a completely clean slate (new language) designed with this in mind.

Such a language would need to be dynamically compiled (of which JIT is one popular flavour), with static (e.g. type) declarations being optional. The stronger the static (e.g. type) declarations you made, the more efficient the compiled code, and the less run-time checks the (dynamic) compiler would need to add. You would have a language with the safety of popular dynamic languages like Ruby & Java, but the speed (where you needed it!) of languages like C & C++. It would allow quick prototyping of idea (e.g. few type declarations), but it could also be used to write software with strong static guarantees (which are good for both self-documentation & providing reassurance that something is correct outside of your test cases). The need for dynamic compilation (few people are capable of doing it) is probably the main thing stopping such a language from being created.

As such I don't think PortablE (nor most other languages) are well suited to going this route. However, it might well be possible to "steal" a few ideas from that hypothetical language, to gain some neat features...

Last edited by ChrisH on 11-Mar-2011 at 02:26 PM.
Last edited by ChrisH on 11-Mar-2011 at 02:25 PM.

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

I have uploaded a new PortablE preview. This fixes a problem with the installer on MorphOS, which caused it to appear to have got stuck.

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

I have now released an UPDATED preview of PortablE. You can download it from PortablE's homepage.

The only change is that PEGCC should no-longer fail with the error message "Failed to strip executable" on AmigaOS4 when you have the source code folder open in Filer, DOpus4, etc. (If a similar problem exists on other OSes, then this will fix it too.)

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

I have uploaded a new PortablE preview. The most important change is that reading & writing of files now works using the 'std/cPath' module. (Thanks to "mrdarek" for reporting the problem!)

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

@ChrisH

I'm happy with new version PortablE. ChrisH very help me coding my game (title is secret now...) so I thank him much.

I have now released an UPDATED preview of PortablE. You can download it from PortablE's homepage.

This fixes some fairly serious bugs with the GUI module, which would stop many parts of a complex GUI from responding to the user.

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

another update especially for my created program. Big thanks for update and for great support while writing my code!