Development of Blake's 7 (was OASIS development)
Development of Blake's 7 (was OASIS development)
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
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.
-
- 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
\o/
My Projects: Replic'Oric Project - StratoCumulus Project
Re: OASIS very very early alpha tech demo
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.
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.
Re: OASIS very very early alpha tech demo
Oh god, Zak McKracken!
Re: OASIS very very early alpha tech demo
What's your current memory layout?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.
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
- 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
Waow, these new demos seems to extend our oric capabilities
Thanks for these new experiences
Thanks for these new experiences
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
Historic owner of Oric, Apple II, Atari ST, Amiga
Re: OASIS very very early alpha tech demo
This is stunning! Can't wait to play it.
Re: OASIS very very early alpha tech demo
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.
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?
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.
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.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
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?
Re: OASIS very very early alpha tech demo
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.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?
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.
- 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
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).
That and swapping disks during the game (which is not that much of a problem with a cumulus or an emulator).
Re: OASIS very very early alpha tech demo
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.
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.
Re: OASIS very very early alpha tech demo
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 .
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 .
Re: OASIS very very early alpha tech demo
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
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
Re: OASIS very very early alpha tech demo
No problem to wait. Enjoy your holidays and have fun!