Development of Blake's 7 (was OASIS development)

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Development of Blake's 7 (was OASIS development)

Post by Chema »

This is OASIS: the yet-to-be Oric Adventure Script Interpreting System.

As I said in the title a very very early tech proof-of-concept and testing. Please ignore the graphics and animations, which are just stubs so I can test things.

I am just playing with some ideas and I am not sure about what the outcome would be (if there is ever an outcome, anyway).

http://youtu.be/VoO0xai1ZJ4

It is the (yet crude) foundations of a scripted engine. Room layout is there, with big rooms which can scroll. The graphic engine is there too (though still some glitches). The basic multi-threading system for interpreting scripts is also in. And I have a lot of notes about other aspects that need to be addressed.

What you see in the video is a couple of characters which are controlled by two concurrent scripts (though a single script could control both, scripts are not tied to characters, of course, but this is a test).

Scripts are bytecode which could be read as:

ActorWalktTo(boy,28,10) ; Start Actor boy walking to column 28 row 10
WaitForActor(boy) ; Waits for boy to finish
ActorTalk(boy, "Hello. This is OASIS") ; Makes boy say the sentence
WaitForActor(boy) ; Waits for boy to finish speaking
ActorWalktTo(boy,5,9)
WaitForActor(boy)
RestartScript()

The second one starts with Delay(20) and moves the girl here and there.

Still thousands of things to do, but I think this is quite solid already. Need to implement many other features for the threading system (more commands, which make use of the possibilities of launching child threads, user and system signals, etc.) and managing of resources (such as rooms, scripts, strings, sounds...) so they can be loaded from disk, deleted and managed (this is quite challenging).

Problem here is memory usage. All graphics are split into 6x8 tiles (as in SkoolDaze) to save space (mostly in rooms which could be large), and they should be stored in memory in a compact way or I'll run out of memory very quickly. Such big graphics for the characters and all the frames of animations are memory hungry.

Just imagine they are 24x48 pixels and I already have 13 different frames for each one and double that for the masks. That is 4x48x13x2 4992bytes if stored directly. I am currently using much less (3440 plus over 600 bytes of overhead) for the two characters. And still it is quite too much, but more intelligent design of graphics could help here.

Anything usable or even eye-candy is really far yet, and I am not sure about the limitations I'll encounter and if I'd be able to address them... But anyway. Wanted to share with you :)
Last edited by Chema on Sat May 20, 2017 6:38 pm, edited 2 times in total.
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: OASIS very very early alpha tech demo

Post by Godzil »

\o/
User avatar
peacer
Flight Lieutenant
Posts: 451
Joined: Wed Jun 09, 2010 9:23 pm
Location: Turkey
Contact:

Re: OASIS very very early alpha tech demo

Post by peacer »

That really feels like famous Sierra adventures like Leisure suit larry, Maniac mansion, King's Quest etc.

I don't know if it is related to scripting issue you explained but seeing such adventure games on Oric would be marvellous :)

Did I ever tell that I always admire your Orical works :)

Thank you.
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: OASIS very very early alpha tech demo

Post by Symoon »

Oh god, Zak McKracken! ;)
User avatar
Hialmar
Flight Lieutenant
Posts: 349
Joined: Tue Mar 04, 2014 11:25 am
Location: Toulouse, France
Contact:

Re: OASIS very very early alpha tech demo

Post by Hialmar »

Awesome as always !
Hialmar
CEO and Silicium member.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS very very early alpha tech demo

Post by Dbug »

Problem here is memory usage. All graphics are split into 6x8 tiles (as in SkoolDaze) to save space (mostly in rooms which could be large), and they should be stored in memory in a compact way or I'll run out of memory very quickly. Such big graphics for the characters and all the frames of animations are memory hungry.
What's your current memory layout?

In my previous demos I used to have the code in lower memory, but for Oric Tech I decided to load the executable directly in $C000 which gives me a totally uninterrupted area from $400 to store all my assets instead of scissoring it in multiple small chunks.

Also think about compression: Filepack would not be fast enough to decompress in real time your sprite animations, but loading and depacking new data sets on the fly is now quite efficient :)
User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: OASIS very very early alpha tech demo

Post by coco.oric »

Waow, these new demos seems to extend our oric capabilities
Thanks for these new experiences
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS very very early alpha tech demo

Post by iss »

This is stunning! Can't wait to play it.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS very very early alpha tech demo

Post by Chema »

Thanks for the nice words, guys :)

There are more technical bits inside the demo than it may seem, however there is still a large way to go. Something similar to those adventure games in the C64 are difficult to do on the Oric. They used hardware sprites, which we don't have here... This means a lot of more work and memory usage (and CPU time).

Once the graphical part is more or less solved, the threading thing is important. The full games are controlled by a script language (quite general, btw), and scripts are resources which are loaded from disk and run in these threads concurrently. There are more types of resources (sounds, for instance, but also objects and even rooms), which are loaded on demand, and discarded when they are no more needed. This all requires among other things some kind of memory compaction algorithms, to avoid huge fragmentation. This is something I am now trying to work in (or at least design).

My script interpreter is nearly empty of instructions. This will come later on. I will start implementing a few I need for testing.

And then will come things like walk-boxes (if you know a bit about SCUMM, you know what they are), z-planes, and so on. Oh, and I don't forget I need to think about a way for user interaction. Not sure a cursor managed by keys is convenient, but could well be. Other thing is that I need to implement the cursor graphic on top of the picture....

Also I still have no idea how would I put all in a disk and load chunks of data which are not aligned to sectors. Probably will need some kind of buffered input :(

And even if I get all that working, it is just the engine. No game. Do you know how they programmed Maniac Mansion? With a compiler done with Lex/yacc to compile sources in a high-level languaje into script bytecode :/ And all the graphics must be done (AIC mode), and sectioned in tiles... Argh.
Dbug wrote: What's your current memory layout?

In my previous demos I used to have the code in lower memory, but for Oric Tech I decided to load the executable directly in $C000 which gives me a totally uninterrupted area from $400 to store all my assets instead of scissoring it in multiple small chunks.

Also think about compression: Filepack would not be fast enough to decompress in real time your sprite animations, but loading and depacking new data sets on the fly is now quite efficient :)
I don't have any particular layout yet. Will have to order things in memory in the end, as you say. I will need to open up space for scripts and resources, so keeping the core of the engine in the upper 16K is a good idea.

Question: Can FilePack decompress as it loads from disk, or do I need to setup a buffer for loading compressed data and then decompress it?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS very very early alpha tech demo

Post by Dbug »

Chema wrote:Also I still have no idea how would I put all in a disk and load chunks of data which are not aligned to sectors. Probably will need some kind of buffered input :(
[...]
I don't have any particular layout yet. Will have to order things in memory in the end, as you say. I will need to open up space for scripts and resources, so keeping the core of the engine in the upper 16K is a good idea.
Question: Can FilePack decompress as it loads from disk, or do I need to setup a buffer for loading compressed data and then decompress it?
If you use the FloppyBuilder system you get automatic packing of data, and the possibility to load any file of any size in any location with 1 byte granularity, the depacking and loading is done internally using a 256 bytes buffer.

Assuming there are no bugs, you can load and decompress a 72 bytes files at address $431 without overwriting the stuff you have at address $479.

Your IRQ will be called between each sector being loaded, so you can technically have small animations and sound playing during the loading.

The only thing that is not implemented is the saving part, so you will have to code that, but you can preallocate areas on disk for your save files in the floppy description file.
User avatar
Hialmar
Flight Lieutenant
Posts: 349
Joined: Tue Mar 04, 2014 11:25 am
Location: Toulouse, France
Contact:

Re: OASIS very very early alpha tech demo

Post by Hialmar »

Using a save disk is also completely on par with SCUMM games.

That and swapping disks during the game (which is not that much of a problem with a cumulus or an emulator).
Hialmar
CEO and Silicium member.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS very very early alpha tech demo

Post by Chema »

Indeed Hialmar. Games use a kind of directory which includes the disk number where a resource is located. Something similar could be done here, if necessary.

Not that I am implementing a scumm machine, but would like to create my own engine... Maybe more Oric friendly ;)

Dbug, and can you load chunks of data to any address? I mean, not hardcoded. I would have to load resources to wherever there is space, which is known only at runtime.

I definitely have to learn how to use FloppyBuilder. Maybe I could create a first basic layout with only a couple of resources and ask you for help if I can't make it work :)

Another thing I particularly hate is the enormous amount of tearing. More noticeable when I scroll the room. This time I can't see a way to sync with the retrace and draw within the blank period.
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS very very early alpha tech demo

Post by iss »

FloppyBuilder is great (Thanks Dbug!).
There are some tricky things (loading address of main program, 2 pass build, etc.), but after I got familiar with it -
FloppyBuilder is simply unique and best for multi-level games and demos with many resources.
For my own purposes I extended the 'loader_api' with some handy functions to be used from 'C':
void LoadFile(int entryindex);
void LoadFileAt(int entryindex, void* addr);
void LoadFileRun(int entryindex, void* addr);
and added #ifdef's to be able to boot in text mode too.
Now I definitely need the 'save to pre-allocated files with fixed size' functionality - I tried to implement it, but no success so far...
I'll be very happy, if one day I find it in defence-force svn :).
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS very very early alpha tech demo

Post by Dbug »

Chema: The default address specified in the floppy description file can be overridden at run time yes.
In the latest version of FloppyBuilder (the one I used for Oric Tech) there's an additional macro that allows you to generate a define containing the unpacked size of the file, that's handy to allocate memory or even do static array allocations :)

Iss: Yes, the "reserve this number of sectors on disk" is not there yet, if that can wait for after my holidays I can probably add that fast :)
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS very very early alpha tech demo

Post by iss »

No problem to wait. Enjoy your holidays and have fun!
Post Reply