Development of Blake's 7 (was OASIS development)

[Godzil]

A solution would be to make a mouse for the Oric....

[Dbug]

A solution would be to make a mouse for the Oric....

Well, there's already three existing pieces of hardware for the Oric that provide something like that:
- The Telestrat mouse, horrible piece of crap which if I remember correctly just spams updates on the serial/joystick port
- The light pen, which returns an accurate Y position and inaccurate X position and requires some tricky timings
- The Graphiscop graphic tablet, which was inaccurate because of the crappy wobbly plastic, but that returned two bytes mapped in memory coming from two potentiometers

I had modified my graphiscop to be upside down, and I was moving the stylus like an analog stick, and for all purpose it was a decent mouse approximation

If you want to make an Oric mouse, make sure the peripheral itself keep tracks of the position and that coordinates can be read directly at any time from registers in page 3, else it's basically impossible to program/use. It has to work with interrupt disabled, with the floppy drive, etc...

[Godzil]

A solution would be to make a mouse for the Oric....

Well, there's already three existing pieces of hardware for the Oric that provide something like that:
- The Telestrat mouse, horrible piece of crap which if I remember correctly just spams updates on the serial/joystick port
- The light pen, which returns an accurate Y position and inaccurate X position and requires some tricky timings
- The Graphiscop graphic tablet, which was inaccurate because of the crappy wobbly plastic, but that returned two bytes mapped in memory coming from two potentiometers

I had modified my graphiscop to be upside down, and I was moving the stylus like an analog stick, and for all purpose it was a decent mouse approximation

If you want to make an Oric mouse, make sure the peripheral itself keep tracks of the position and that coordinates can be read directly at any time from registers in page 3, else it's basically impossible to program/use. It has to work with interrupt disabled, with the floppy drive, etc...

Would you prefer something that is on the Ext bus or on the printer bus?
And making it "intelligent" and read either absolute or relative position from a set of register in the $03xx page is really easy

Do you have any preferences for the registers address if using the exp port? (2 registers is my preference, one to select the data to read/write, the second to read it! (or write for any configuration)) leaving 256 possible registers to read/write for only 2 address used.

Using a standard PS2 mouse is ok for everyone? No sorry I don't plan to support USB mouse, or only the one that work with a USB to PS2 adapter.
Maybe ADB mouse could be supproted, but clearly no USB, sorry

I have already a general idea on what to do for the exp port, just need your input for the addresses to use, and I already know the uC to use for that.
This would me some sort of a passthroug device on the Exp Port that does not prevent to use a real microdisc or a cumulus or whatever

[Chema]

I like the idea of having a "quick move" extra key... I was thinking about accelerating the speed when the user keeps the keys pressed, which is something that was done in some speccy games and worked quite well, imo. Problem with the extra key is that it is difficult to support joysticks.

I will test and see what happens.

BTW I plan to let the user redefine the keys as I did in Oricium.

About the number of verbs, indeed modern implementations have some kind of default action and remove the verb list. But you usually have some "Extra" actions using the right mouse button, needed when there are several possibilities. You can, for instance, "walk to", "look at" or "talk to" an actor (and maybe others). Guessing the best (and correct) option automatically removes much of the fun. Opening a list of options to select from as a kind of context menu (graphical or not) seems too complicated.

That is why I used the system in MI2, with just 9 verbs and auto highlight (showing the name of the object if the cursor is over it), things that were not in Maniac Mansion and made it a bit cumbersome to use. In my opinion it is a good balance between the number of options and flexibility, while giving the game this "retro" and "scumm" look that I really like.

Anyway, time will tell.

[iss]

As Dbug mentioned light-pen is an option. It's emulation works pretty well in Oricutron
and supporting it is really easy, so, as temporary variant and for debugging purposes
may be it's worth to be used. Just my two cents...

[Godzil]

As Dbug mentioned light-pen is an option. It's emulation works pretty well in Oricutron
and supporting it is really easy, so, as temporary variant and for debugging purposes
may be it's worth to be used. Just my two cents...

My problem with a light pen is apart for the emulation, nearly no one have one on the Oric, plus the amount of code needed to make it working, I don't know the one existing on the Oric, but I don't think it's that easy to use. (for the programmer)

I finish the "difficult" part of my current project, then I'll do the Oric Mouse, then resume on the Cumulus Rev2. I plan for the Oric Mouse on a really cheap device, so everyone could afford it

[peacer]

Programming lightpen is not so much diffucult. But natural usage of lightpen is not as as flexible as mouse. i.e. you have to click continuously to keep tracking od the cursor.

Once I've wrote a simple program using lightpen emulation to show ability of lightpen. Its so primitive, has lots of bugs but can give the idea.

But, i admit, creating a program which can only run under emulator is nonsense...

[iss]

All light-pen critics are accepted, but I clearly stated: "as temporary variant and for debugging purposes".

[Chema]

I did not consider supporting mouses or lightpens... not even for debugging purposes (thought it is a good idea). I thought that most people only have the keyboard or (at most) a joystick. Even supporting joysticks is not easy (which model? how to do it without affecting sound?); just read the Wiki where Twilight wrote about that. Some joysticks could (and should) be supported if they do not corrupt sound, though.

That is why I am trying to make it easy for the player to work with the keyboard, but most importantly, to get a system where the user doesn't have to fight against the interface, instead of using it.

Apart from the current speed and imagining I can include a system to accelerate its movement (with an extra key or by keeping the key pressed), do you think that the current demo shows a good user experience, even using the keyboard? I know it is a bit difficult by just watching a video, but surely you played MI2...

I think it is a good improvement over Maniac Mansion and similar games, without the need of including much complexity.

For instance. I was thinking about doing something:

Imagine you have a room with a closed door and a key on the floor. You want to get the key and open the door with it. The usual way of doing this would be selecting "PICK UP" then click on the KEY ("PICK UP KEY"). The character moves towards the key and picks it up, appearing in the inventory. Then you can select "USE" then the Key in your inventory ("USE KEY WITH") and then click on the DOOR ("USE KEY WITH DOOR"). The character would move towards the door and try to open it.

A more intelligent approach would be to choose "USE" then click on the KEY ("USE KEY WITH") then on the DOOR ("USE KEY WITH DOOR"). This would set the character on his way towards the key, pick it up, then move towards the door and try to use it.

The problem with the second approach is that it would be much more difficult to program (in a general way, it will need to keep track of several consecutive actions, not just one). It can be done of course, but is it worth it? The extra code with all the possible exceptions will be important. So if you would not mind to use the step-by-step approach things will be way easier and the code will be more compact.

These are the kind of things I have to consider at this step, I think.

As a side note, the full engine as it is now is something below 9K (including the data needed to work, for instance managing of threads, variable space, data of objects to deal with,...), where something over 10K are eaten up by the resources (room layout, graphics, scripts, texts...).

Oh, and I was following the path of the first games leaving the upper line for texts (which will be colored to differentiate between actors or game messages). But it *could* be possible to use the technique in Skool Daze with speech bubbles and scrolling text. This will be much more complicated, but I am not sure if it will be worth it. Anyway it is something that could be decided at a later stage.

I also plan to make the engine load script 0 and run it as the entry point of the game. The game programmer will put in that script any initialization needed, loading the first room (which could be a title screen), objects, other scripts, whatever. There will be another special script (number 1) where the game programmer will put all the default messages for actions when they are not handled by object scripts (typical "I don't know how to do that", or "That has no effect"...). Even of most of the time there will be specific messages, there will always be cases left unhandled.

*BEG MODE ON*
And I was hoping in vain to hear someone saying "I will write a graphical editor (PC/Windows at least) for the rooms, supporting AIC and tiling, just drop me a note" or "I will write a compiler so the game designer can use a much high level language which is compiled in script code"...

Else, I will also have to do that
*BEG MODE OFF*

[Chema]

Thinking about it, I guess there will be very few occasions in which merging the pick up/use actions wicould be useful. It would be a too simple puzzle... And I can't think other options where it could be used to justify the additional code.

If you can imagine any...

[Symoon]

Problem with the extra key is that it is difficult to support joysticks.

If you are talking of the user point of view: depends on the joystick type.
Some games like Mercenary were designed for a combination keyboard + joystick. Too bad for the ones that required two hands

BTW I would suggest not to use the light pen.
Its emulation is way too optimistic, working easily, but... The real one is a real pain, especially as it doesn't operate at all on some coulours (red for sure, and maybe dark blue).

[Hialmar]

I just read this (well in fact it's translation in French posted on obligement.free.fr):
http://passfieldgames.blogspot.com.au/2 ... -20th.html

It's an article about Flight of the Amazon Queen. Maybe some of it could bring you some ideas, Chema.

[Chema]

Thanks for the reference, Hialmar. Really interesting indeed. I will read through it carefully, as it contains very nice ideas...

BTW, you can see there how creating nice animations would eat up all the memory :/ Obviously the game will look nice in the end (with AIC graphics and so on). Also there is not obvious reason why not to use a graphical menu (with actions) or inventory, apart from memory usage and clarity. Surely could be added later.

You know I first like to add the core of the engine, and then work out the visuals.

[Hialmar]

Yes sure. I just read this and thought about OASIS so I figured I would post about it here.

I'd like to help but I'm way too noob on ASM to be any help I fear.

[Chema]

Hialmar, when I said "You know" it was meant in plural I should also have written "you know, " with a comma, I guess.

I was trying to stress that I was concentrating on the engine, but in the end good-looking graphics, colors and fonts will be used. Or i'll try to.

I have been working quite a lot on this, but unfortunately nothing that can be easily shown. I had to rework how sprites were drawn and the "hot spot" for character locations. I was using the upper left corner, which is not convenient. I also worked a lot polishing, reorganizing and cleaning the code, hunting some bugs and changing how some structures were handled.

I also worked on the actions which require two objects (such as give and use). In fact use is a bit more complicated, as it can have one or two objects, so it is not fully working yet. The engine does quite a lot of work for the programmer, while letting him have a lot of control of what goes on using the scripts. Or that I hope

Whenever you select an action over an object, the "object code" resource is examined, as I already told you. When using two objects the code should reside on the second object. You can select objects from the screen or the inventory. The engine will check and make the character move towards the first object which is not in the inventory (if both are, then no movement is issued). The rest can be handled by the user script.

I also decided to have at least two special scripts. Number 0 is loaded and run at the beginning, as an entry point to the game. Number 1 is a default script which is called whenever an action cannot be done (an appropriate response has not been found on the object code). Could do something as simple as making the ego say "That did not work", or something more elaborate, depending on the objects, actions, game flags, random events...

givekey2girl.png (11.33 KiB) Viewed 17835 times

Another thing I included are props. In some occasions you want to have objects in the room which are not animated, are just part of the background, but still the player can interact with them and are highlighted when you hover the cursor over them. Even if it is just a special place and you want the user to see a "WALK TO DARK CORNER". Also useful for pictures or notes on the walls you can read, and so on. Making them usual objects with sprites, masks, etc. would be quite of a waste, so I decided to include this kind of objects which only have a position and a size and, of course, object code and other internal properties. I think this could be nice to add life to a room without needing too many resources.

And a good example could be doors (as long as they cannot be open/closed), so you can WALK TO DOOR and enter it to go to another room (the action of going to another room is stored as a script in the object code, so the programmer can do really complex things with this).

closedoor.png (7.17 KiB) Viewed 17835 times

So, as you can see, many small but yet needed advances. Including a mouse cursor which accelerates if you keep the keys pressed; it's probably even too fast on some occasions.

Now there are many things that still worry me. Some optimizations for the drawing engine rely on having data aligned to page boundaries. To keep the story short, if they are loaded from disk this will be difficult to guarantee and should probably be dropped. And all those routines changed.

But even worse, and this is for the 6502 code gurus out there. You will like to have some room decorations you can walk in front of or behind, like a plant or a fence. If they are objects (such as the box) it is easy, but for large complex decorations it would be a waste. SCUMM had zplanes: bitmasks stored after the graphic which are applied to prevent a sprite to corrupt the background so it appears behind things. Attaching an actor to a zplane is easy using walkboxes, and the thing is getting the bitmask corresponding to its zplane and applying it.

But I can't find a way to do this efficiently. Bitmasks would be stored in tiles, such as room graphics, no problem here. The pointer to the correct tile can be precalculated, but adding this to the draw loop... argh.

The core of the loop is (mask_p and graphic_p are self-modifying code addresses):

Code: Select all

	ldy #7
loopcopy
	lda backbuffer,y
	bpl ScreenNoInverse
	eor #63
ScreenNoInverse
mask_p
	and $1234,y
graphic_p
	ora $1234,y
	sta backbuffer,y
	dey
	bpl loopcopy

Which is the best way to include this second mask?