A.D.A. Amiga Demoscene Archive

Hi,

Anyone else here use AMOS Basic, or do you all program in C or assembler?


I could do with some tips on scrolling the screen sideways for a platform game - such as how to draw the level (just offscreen) before it becomes visible.
I could draw the level all at once at the start, but that method would require an extra large screen (eg. 1200x250).


Regards,
Lonewolf10

For a horizontal scrolling game :
Use a large playfield of 2 screens in size. Lets show it as

BBBBAAAA

The Bs is the visible screen as you enter a level.
A is empty area where nothing has been drawn yet.

The sequence below shows what you must do when scrolling right.
XYZW are the new tiles to be scrolled in from the right. You need to draw the new tiles both in front where the level is scrolling in and behind where the level has scrolled out. The pipes marks the currently visible area.

|BBBB|AAAA

Draw the incoming tiles in front of the visible area

|BBBB|XAAA

Scroll right by the tile width and copy the X behind once it is fully visible at the right.
X|BBBX|AAA

X|BBBX|YAA <- draw the X behind the screen and draw the new tile Y
XY|BBXY|ZA <- Scroll right by the tile width, draw Y behind and Z as new
XYZ|BXYZ|W <- Scroll right by the tile width, draw Z behind and W as new
XYZW|XYZW| <- Scroll right

Now we have reached the end of the visible area, but the offscreen area to the left is the same as the visible, so we can reset the scroll position and continue moving right and drawing like above afterwards.

|XYZW|AYZW
A|YZWA|BZW
AB|ZWAB|CW
ABC|WABC|D
ABCD|ABCD

.. yay.. Very nice explanation I'm sure :) 2:44 .. ooh

hehe... yes it is late isn't it (2:09am here in UK) - I don't have work til Thursday though ;)

Thanks for the explanation. I did think of something similar but was constantly scrolling the screen.. so when the far left of it came back around on screen it was 1 pixel higher than the far right of it, which meant that when I reset the position of the screen it jerked down and erked me somewhat.

I'll get coding on that tomorrow ;)


Regards,
Lonewolf10

I can't believe I read about AMOS again. :)

If you need a trackloader for your upcoming platform game, I could offer you WickedDOS which is a complete multi-drive disk-system written in AMOS.

AMOS is truly amazing for prototyping of graphical stuff. You can just get to the point so extremely quickly.

For instance, write this tiny AMOS program:

Cls 0
Do
If Mouse Key
Plot X Screen(X Mouse),Y Screen(Y Mouse),Mouse Key and 1
End If
Loop

And you have a small drawing program! Try doing THAT using some modern graphics/input API! ;-)

(It doesn't work too well in WinUAE, though, since WinUAE only emulates the mouse movement once per frame.)

That leads me to a (slightly off-topic) question: Does anyone know of a modern programming system of some kind which is similarly accessible for this kind of prototyping? I know that some people use Lingo for this kind of thing. Is that any good?

It would be nice to have some PC-based prototyping system to use for Amiga effects, so that it doesn't matter that the language used for the prototyping is awfully slow (it will still be much faster than the real Amiga anyway).

@Blueberry,

Even though it's not great for doing animated stuff, I tend to prototype things in Matlab. You can also try Octave which is a free-ware matlab clone, it lacks some essential things but for trying out effects it's more than enough.

I think there's a version of blitz basic for modern PCs

yep, still coded by Mark Sibley/Acid Software. It's very nice and simple, compiles code for MacOS, Linux and windows and has some nice OOP (if you need it) but still remains the simplicity. http://www.blitzmax.com/

I am very happy with Python at the moment. Haven't used it for any effects coding, but I have checked the PyGame API (based on SDL) and it looks cool.

Yeah, I've been thinking about Python as well - the language has very much the right non-complicated style. Is there a simple graphics/input API for Python which doesn't drag the programmer through the whole OpenGL/DirectX business or lots of weird setup boilerplate code?

@bonkers: Well, Matlab is good for, well, mathematical things. I couldn't imagine using it for demo effect prototyping. How do you plot pixels and wait for vblank in Matlab? :-)

PyGame is a Simple Direct Media (SDL) wrapper. I already enjoyed SDL itself as a great way for easy cross-platform graphics + more. PyGame should make it even more convenient to use SDL. As I said, I haven't used it, yet. But it looks good and is high on my list of to-do things.

Check their introduction article which comes with example code that bounces a ball around the window.

Yeah, PyGame acually looks quite accessible: Set resolution (or open window), draw to surface, swap...

Looks like it is time to implement my 3D engine and other stuff in Python as well. ;)

You could also generate a Python module from a working C/C++ source or use the ctypes module if you already have a DLL of your engine.

Psycho might also be worth considering to speed up Python code on any x86 environment once you have written something that gets too slow but before reimplementing it in C.

Who said anything about C? ;)

Prototype in Python, implement in assembler. The Python program could also be used to generate some data and code for inclusion into the assembler program.

I don't think the speed will be a problem. I don't know how fast Python is, but I would be surprised if Python on a 1.6GHz PC isn't able to match the speed of assembler on a 50MHz Amiga. :)

My preference for a prototyping language would be :
- No includes
- No need to link to any libraries
- Screen should already be set up at init time
- No crashing when running your program
- Running the program is 1 click away

In Amos that would need no code at all and only require you to press F1. How does Pygame or Blitz fare in this case?

Python with PyGame:
- No includes .. tick
- No need to link to any libraries .. no linking (but you put an import statement in your code, e.g. import pygame)
- Screen should already be set up at init time .. nope, but you get it quickly set up in a few lines
- No crashing when running your program .. so so (your machine wouldn't crash, but you could generate e.g. orphaned windows if you are careless)
- Running the program is 1 click away .. tick

3+/5

PS: If you really want AMOS back, you could check Alvyn Basic

Let's see how pyGame fares here...

- No includes

import pygame
pygame.init()

Now that wasn't so bad, was it?

- No need to link to any libraries

Once you have installed pyGame in the right place, that should work automatically.

- Screen should already be set up at init time

pygame.display.set_mode((320,240))

And you are ready to draw. You will have to do that in AMOS as well if you want anything but 320x200 in 4 colors.

set_mode also takes some optional parameters and flags for things like depth, fullscreen, double buffering, ... Quite convenient to have it all in just one call.

- No crashing when running your program

That's right. Python is modern enough to have real exceptions for that kind of thing. :)

- Running the program is 1 click away

Since Python programs do not need to be compiled, this will just be a matter of setting up your editor to run the program at your desired command.

It seems to me that pyGame could indeed be quite a worthy successor to AMOS. :)

And Python will be the "new" ARexx in a future AmigaOS update (ARexx will still be there of course, but AmigaPython will be able to send & receive commands via ARexx ports).

If you need a trackloader for your upcoming platform game, I could offer you WickedDOS which is a complete multi-drive disk-system written in AMOS.

Sounds interesting. Can you email it to me, or do you have it on physical disks? Either way I'm definately interested :)

I have been programming in AMOS since 2001 (when I first got my Amiga 600 2nd hand off ebay).


Regards,
Lonewolf10

AMOS is truly amazing for prototyping of graphical stuff. You can just get to the point so extremely quickly.

For instance, write this tiny AMOS program:

Cls 0
Do
If Mouse Key
Plot X Screen(X Mouse),Y Screen(Y Mouse),Mouse Key and 1
End If
Loop

Not sure if that would actually work. I understand the theory, but the last bit on the Plot statement

"Mouse Key and 1"

confuses me a little.

Also, I think you'll find that's going to plot black pixels (black is default colour remember?) on a black background (you used Cls 0)!
All that aside, yes it is easy to make simple programs like that :)


Regards,
Lonewolf10

(Edit - originally put "If statement" but meant "plot statement")

My preference for a prototyping language would be :
- No includes
- No need to link to any libraries
- Screen should already be set up at init time
- No crashing when running your program
- Running the program is 1 click away

In Amos that would need no code at all and only require you to press F1. How does Pygame or Blitz fare in this case?


The no need to link to libraries isn't strictly true.... you need "c3d.lib" in the "AMOSPro_System" (or is it "Libs") draw for the 3D stuff, and possible INtOS files if you use INTos. If you don't use 3D then AMOS doesn't require anything external once compiled.


Regards,
Andrew B
aliensrcooluk@yahoo.co.uk

- No crashing when running your program

Missed this. AMOS *will* crash under certain circumstances - such as Bloading in a file larger than a reserved bank, or poking wrong values to certain parts of memory. I guess the latter doesn't count as that can happen in any language.


Regards,
Lonewolf10

Not sure if that would actually work.

It does work. I tried it. ;)

I understand the theory, but the last bit on the Plot statement

"Mouse Key and 1"

confuses me a little.

Mouse Key returns 1 for left mouse button, 2 for right. By and'ing with 1, I get 1 for left, 0 for right. Hence, I can draw with the left button and erase with the right. :)

Also, I think you'll find that's going to plot black pixels (black is default colour remember?) on a black background (you used Cls 0)!

The defualt color is overridden by the third argument to Plot.

So, with the default palette, I am drawing with brown on a black background. Not exactly pretty, but hey, it was just an example! ;)

Poke staments have to be dangerous, otherwise what are they good for. And preventing buffer overruns would limit the programmers' ability to make exploitable programs.

I'm starting to believe Get Block and Put Block are buggy. I get random "illegal block arguments" and the put block draws a bit beyond the area getted by Get Block.. nngghh..

I check for width=0, height=0 and coordinates outside screen. Anything else illegal that I have to check for?

I use them for Undo functionality in a drawing program as Put Block should restore a block at the place where it was first fetched using Get Block...

rload: please, just try blitz ;) you are already familiar with AMOS, so it's no more than two hours to learn the syntax.

look:

Graphics 320,256

While (MouseDown(2)=0)
Plot 42,42
Flip()
Wend



....no includes! \o/ i even threw in double buffering for free with the Flip() ;)

The amos sources are for download :) so now you can fix those annoying bugs. Thanks to Frequent for tracking down this one for me.

http://www.theclickteam.com/eng/downloadcenter.php ?i=58

rload, better said for us: you prepare somethink good for bp09 ?:)

@kasie : first, all tv-series must be put to an end, then chatting must cease, then maybe :) I have to turn off internet to get something done!!

http://www.processing.org is the shit..