Amiga Development > Application Development

Athanor 2 - an adventure game

(1/2) > >>

Athanor 2
The Legend of the Birdmen

An Adventure game for the the 16/32 bits machines (Atari ST/Amiga) by
Game created by Eric Safar, including the story & ST version.
Original graphics designed by Angel Bautista.
Graphics colorization and Amiga adaptation by your truly.
Additionnal graphics colorization by Vincent Jambut.

In this thread, exclusive to AmigaLife, I will try to post updates, as much as possible, about my progress of the Amiga adaptation of Athanor 2.
This project started super slowly around 2015. It is mostly based on the original Amstrad CPC version, using the same original drawings, except that everything was re-colored from the ground up.
The game itself is programmed in C, targeting the OCS Amigas, including the good old unexpanded A500.
Stay tuned!  8)

Let's start with a video capture of the current WIP version :

As said above, the game is programmed in C.

The video shows the game running directly on the scenario data of the ATARI ST version. All the data are massaged in Python and reinjected in the C project.

The graphics (GUI & sceneries) are in 32 colors specifically converted to the Amiga OCS. The sprites are (temporarilly) untouched bitmaps of the ATARI ST version.

This video shows the first basic routine to handle the game inventory. The player can grab objects, they are added to the inventory. If an object is in the inventory it is considered to be in the hand of the player, thus simplifying greatly the game's puzzles. This is temporary as well.

Some of the texts are not the correct one, for some reasons yet to be investigated ^^;

I hope you will like it :)

Cool concept, following this project :) Keep on the good work ..


--- Quote from: kriz on July 09, 2019, 09:47:55 AM ---Cool concept, following this project :) Keep on the good work ..

--- End quote ---

thanks! :)

Tonight, I worked on the mouse pointer, to have it reflecting dynamically the current action:





The PNG -> Hardware sprite conversion was done with Png2Image, a set of Python scripts originaly created by Wei-ju Wu

While working on the game, I occasionnaly test it on various configurations, including the bare bone A500 without any RAM expansion.
That means that the game should run with only 512Kb of CHIP RAM.

This shouldn't be an issue for this genre of classic adventure game, but remember that everything is done using the AmigaOS calls, and even on an A500 the game is supposed to be OS-Friendly.

I tried to reclaim memory occupied by the CLI/SHELL screen + window opened by AmigaOS1.3 when booting the game (the game starts using a regular startup sequence) but it turns out the game itself cannot invoke CloseWorkBench() or even EndCli(). 1st option will fail silently, 2nd option will shutdown the game (as it seems to be a child taks of the CLI that we are trying to end).

Anyways... I used a fallback strategy : add21k, aka add44k, aka add36k.
All of these tools use the same trick : remove one of the bitplanes from the CLI/Workbench screen to free as much memory as possible.

I found one of these on Aminet, and it includes the source code :

So I decided to borrow the routine and add it to the R-Page engine.
The result looks like this :

--- Code: ---/// Add36k does nearly the same as 'subbp' or 'add21k', exept that it does not
/// only free 21kb of memory (one std. workbench plane), but in fact 36kb of
/// memory (that is one plane and 250 lines of the others).
/// Original code by Alexander Rawass
VOID add36k(struct IntuitionBase *ibase)
long pl0,pl1,plb,ple;
struct Screen *scr;
struct BitMap *bm;
struct Window *win;
ULONG origheight;

if (ibase != NULL)
scr = ibase->ActiveScreen;
win = ibase->ActiveWindow;





--- End code ---

Once added to the project, it allows the game to allocate more memory to its internal cache. That means the player will have to wait less time when going from a place to another, as the screens/places he visited will remain longer in memory, thus reducing the disk access.

In the end, I might spare this extra memory for something else. Stay tuned!

Without add36k, the screen cache is 90Kb large :

When calling add36k, the screen cache is 135Kb large :


[0] Message Index

[#] Next page

Go to full version