Athanor 2 - an adventure game

[Astrofra]

Athanor 2
The Legend of the Birdmen

An Adventure game for the the 16/32 bits machines (Atari ST/Amiga) by SafarGames.fr
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 with 1MB of RAM (either 512KB CHIP + 512KB SLOW or 1MB CHIP).
 
Stay tuned! 

[Astrofra]

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

[kriz]

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

[Astrofra]

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

thanks!

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

LOOK



TAKE/DROP



USE



TALK


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

[Astrofra]

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 :
https://aminet.net/package.php?package=util/misc/add36k.lzh

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

Code: [Select]

/// 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;

origheight=scr->Height;
SizeWindow(win,0,-150);

Delay(1*50);

scr->Height=50;
scr->Depth=1;
bm=&scr->BitMap;
bm->Rows=50;
bm->Depth=1;
pl0=bm->Planes[0];
pl1=bm->Planes[1];
bm->Planes[1]=NULL;
plb=pl0+(640*50/8);
ple=pl1+(640*origheight/8);

RemakeDisplay();
FreeMem(plb,ple-plb);
}
}

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 :
 

[Astrofra]

Lately, I replaced the system-friendly "flash/bell" call (DisplayBeep()) by a simple visual FX, inspired by MacOS X :



I could (should ?) have used an interruption to handle this, but instead this is just a simple piece of code I'm calling from within the main update loop of the game :

Code: [Select]

void __inline gui_update_fx(void)
{
    // Shake
    if (fx_shake >= 0)
    {
        int x_screen, easing;
        x_screen = (sintab32[(fx_shake << 7) & 0x3FF] * fx_shake) >> 14;
        rpage_video_scroll(x_screen, 0);
        fx_shake--;
        if (fx_shake == 0)
            rpage_input_enable(TRUE);
    }

}

The core of the FX is the famous hardware scroll of the Amiga, controlled by the graphics.library (yaye) :

Code: [Select]

void __inline rpage_video_scroll(short x, short y)
{
    if ((scr_x_offset != x) || (scr_y_offset != y))
    {
        main_screen->screen->ViewPort.DxOffset = x;
        main_screen->screen->ViewPort.DyOffset = y;
        ScrollVPort(&(main_screen->screen->ViewPort));
    }

    scr_x_offset = x;
    scr_y_offset = y;
}


[Astrofra]

Athanor 2, game dev warstories 

The most funny glitch I had when working on the game’s display is one well documented side effect of the Amiga’s parallel architecture. As the blitter and the CPU works concurrently, you need to take care of which one is the fastest...

Turns out the result really depends on the Amiga model. On the basic A500 everything might be ok.

Let’s say :
- malloc() and load a bitmap from disk
- blit it to the screen
- free() the bitmap

Problem:
On a faster 68k machine with the same OCS blitter, turns out the free() might occur before the blit is completed, leading to a garbaged display, as the blitter goes on with the blitting stuff while the data is not available anymore.

This happens especially if you do like me, cleaning all the bitplane pointers table after freeing it

Code: [Select]

void free_allocated_bitmap(struct BitMap *allocated_bitmap)
{
if (allocated_bitmap)
{
UWORD i;

if (allocated_bitmap->Planes[0] != NULL)
FreeMem(allocated_bitmap->Planes[0], RASSIZE(allocated_bitmap->BytesPerRow << 3, allocated_bitmap->Rows) * allocated_bitmap->Depth);
else
printf("free_allocated_bitmap() error, plane ptr should not be NULL!\n");

for (i = 0; i < allocated_bitmap->Depth; i++)
{
if (allocated_bitmap->Planes[i] != NULL)
allocated_bitmap->Planes[i] = NULL;
}

if (allocated_bitmap != NULL)
{
FreeMem(allocated_bitmap, (LONG)sizeof(struct BitMap));
allocated_bitmap = NULL;
}
}
}

Solution:
To solve workaround this issue, I ended up with a blocking call to WaitBlit() do that the free cannot occur before the blitter is done...

We're talking Adventure Game, here, performance is not a real concern 

[Astrofra]

GUI Stuff

For some various reasons, I needed a somehow generic GUI toolbox in Athanor, but being not super fond of the look of the OS GUI, I quickly hacked my own dialog box.



I started this because there's a moment in where the game needs some keybd input from the player.
The "OK/Cancel" buttons are generated by a couple of lines of code, so is the textfield.
Most of the GUI stuff is based on a couple of functions that works more or less independently. No class, no OOP here.

Code: [Select]

void gui_draw_3d_button(rect *_r, BOOL hilite)
{
    rect r, r2;
    short col_black = 0,
            col_med = 14,
            col_light = 20,
            col_white = 19;

    if (!hilite)
    {
        col_med = 12;
        col_light = 17;
        col_white = 29;
    }

    memcpy(&r, _r, sizeof(rect));

    rpage_video_fill_rect(&r, col_black);
    rect_shrink(&r, 1);
    rpage_video_fill_rect(&r, col_med);
    memcpy(&r2, &r, sizeof(rect));
    r2.sy = (r2.sy + r2.ey) / 2;
    rpage_video_fill_rect(&r2, col_med - 2);
    rpage_video_draw_rect(&r, col_light);
    rpage_video_set_pixel(r.sx, r.sy, col_white);
    rpage_video_set_pixel(r.ex, r.ey, col_white);
}

At some point, I found out I could use this buttons for some other purpose, like :

Asking for a disk swap

(he says he wants you to insert disk 1)

Loading/Saving the game's progress


- By the way, will the game be in English, too?
- SIR, YES SIR!



Nothing crazy but it looks cute, don't you think?

[Astrofra]

Ladies & Gentlemen, Boys and Girls, People, Folks, here is a pre-release video of the (soon to come) Amiga OCS Version of ATHANOR 2 - The Legend of the Birdmen :