UMoria BBC BASIC Port.

[Gazza]

As promised in another topic, here is a snapshot of what I have so
far. It is by no means all done. I've still got to figure out some of
the more complex stuff and architecture specifics. However, you can
see how what I have got done figures in all of this.

A couple of notes to say here. Rather than re-coding all the structure
type stuff out of the equation, I've hacked up a number of read/write
handlers for each of the object types which approximate to the best of
my ability, what the C++ code was doing. Therefore there may be a
quicker way of doing this. Calls to FNs/PROCs ending in "_readdata",
"_writedata", "_incdata" and "_decdata" from within the BASIC code are
examples of this. There are others, but I've been dealing with
populating the object and monster databases for a while now and
haven't taken a look at the game code for over a month...

http://www.garethlock.com/acorn/umoria/devtools.zip : Contains
development tools and associated shared code.
http://www.garethlock.com/acorn/umoria/moriawip.zip : Contains the
bulk of the code I've already ported.

Again... Not all the source files are complete and not all the source
files are present. I haven't tried grouping all the code together yet.
The directory viewer just contains displays the BASIC equivalents of
the C++ source.

Hope you enjoy it...

[Martin Hansen]

Hi Gareth,
Stuck a link to this on RISCOScode.
Nice progress update, thanks.
Martin.

[Gazza]

Thanks for the publicity, but it's at least 3 months off being able to
run it, leave alone getting the bugs out of it. I'll keep this post
active with any other developments.

[Gazza]

Corrected a glaring bug in the Damage editing option in !MkCList. I
was checking "5," rather than "5". (WHEN "3","4","5,","6" : REM Foo).
Silly Me! Don't know why I hadn't spotted this earlier.

Got some more monster records entered into the database.

[Gazza]

Another minor bugfix, this time to a routine in the Glue library (!
MoriaDev.Common.Glue) this is the routine that takes a string
representing a hex number as a parameter and performs the validity
checks before returning a number. The routine is called
dev_gethexfromstring() and I think It's the first one in the file.
(Very close to the top anyhow.) I haven't posted the updated files
yet, but to add the fix yourself, just add the following line
immediately after the LOCAL declaration at the start of the routine.

hex$=LEFT$(hex$,FNdev_getlastchr(hex$))

This fixes an issue where a string containing trailing spaces but with
an otherwise valid hex number was always returning 0. "FFA5 " would
return 0 rather than FFA5.

In other news, that's all the monsters defined. Now for the third big
static data table. Monster Attacks.

[Gazza]

[Steve Drain]

On 05/09/2011 12:31, Gazza wrote:
> Another minor bugfix, this time to a routine in the Glue library (!
> MoriaDev.Common.Glue) this is the routine that takes a string
> representing a hex number as a parameter and performs the validity
> checks before returning a number.

SYS"XOS_ReadUnsigned",16,hex$ TO ,,num%;flags%
IF flags%AND1 THEN <not valid> ELSE =num%

This ignores leading spaces and reads the string up to the first non-hex
character, ignoring the rest. It accepts a leading '&' if present. Hope
this helps.

[Gazza]

Thanks... I'll look into it, but the routine I've written will take PC
representation "0x12345" with the optional "L" to signify a long INT
as well as the more conventional "&12345" that's used on the Acorn/
RISC OS platform. The original data tables came from C/C++ source
written to compile on a PC, so all the hex notation is like this.

[Rick Murray]

On 08/09/2011 03:15, Gazza wrote:

> Thanks... I'll look into it, but the routine I've written will take PC
> representation "0x12345" with the optional "L" to signify a long INT

My little (half-finished) assembler pick up "0x" and parse it as a hex
by OS_ReadUnsigned. I don't support "L" suffix, but that'd be pretty
simple to add, either by looking for 'L' or just looking for non-numerical.


Best wishes,

Rick.

[Steve Drain]

I would look to alter the data to fit the fast routine I already have. A
quick search and replace in StrongED or Zap would do that in this case.
Often, more work formatting static data can save a lot of programming
effort.

Even so, it takes only one line before the above to detect '0x'. I think
the 'L' suffix is irrelevant with RISC OS integers so you can ignore it:

IF LEFT$(hex$,2)="0x" THEN LEFT$(hex$,2)=" &"
or
i%=INSTR(hex$,"0x"):IF i% THEN hex$=MID$(hex$,i%+2)

Of course, if you were using Basalt the original two liner could be
replaced by:

num%=NUM(hex$,16)

;-)

[Gazza]

On Sep 9, 11:16 am, Steve Drain <st...@kappa.me.uk> wrote:
>
> I would look to alter the data to fit the fast routine I already have. A
> quick search and replace in StrongED or Zap would do that in this case.
> Often, more work formatting static data can save a lot of programming
> effort.
>
> Even so, it takes only one line before the above to detect '0x'. I think
> the 'L' suffix is irrelevant with RISC OS integers so you can ignore it:
>
>     IF LEFT$(hex$,2)="0x" THEN LEFT$(hex$,2)=" &"
>    or
>     i%=INSTR(hex$,"0x"):IF i% THEN hex$=MID$(hex$,i%+2)
>
> Of course, if you were using Basalt the original two liner could be
> replaced by:
>
>     num%=NUM(hex$,16)
>

> ;-)- Hide quoted text -
>
> - Show quoted text -

OK... Will investigate further.

In other progress news, I've completed all but the CSV dump code
portion of the !MkMAttk.!RunImage conversion and started punching in
the m_attack_type data table. As far as I can see, the last of these
mamouth data tables. I have removed the mkobj.zip file mentioned in a
previous topic from my server, as it has served it's purpose and
everything in it can be found in the devtools link. If you are using
the devtools you will need to download moriawip.zip as some, if not
all of the devtools write their output into the !DBMoria application
in their final destination where the game code expects to find them.

Yes... I know this is not ideal practice when running the game, and
the game code behaves correctly when writing configs, but it makes
sense to me in a development environment to write the files where the
eventual program expects to see them, rather than manually copying
them from some temporary loaction by hand.

[Gazza]

Finally got the last of the m_attack_type data in. !MkMAttk is still
missing CSV dump code. I'm hoping to, at least start, fixing that
tomorrow. I'll upload the changes tomorrow night. The only real change
is the extra m_attack_type data. I've removed the predictive attack
value code, as it wasn't smart enough and it was cumbersome and wasted
about as much time as it saved.

So... Until tomorrow when I upload... Enjoy.

[Gazza]

In further news, the changes described in my last post have been
uploaded and can be obtained by using the following links. (In case
anyone's lost the starting post somehow.)

http://www.garethlock.com/acorn/umoria/moriawip.zip - Progress on
the C/C++ source.

http://www.garethlock.com/acorn/umoria/devtools.zip - Development
tools.
All written in BASIC, these include the data entry tools described in
this thread along with a few backend libraries. These can be found by
shift-clicking into the app and navigating to the Common directory.

Common.Glue : This contains definitions to all calls starting dev_.
Most of this stuff is pretty generic, it's been hived off as it is
used by all the data entry routines and the Statics parser "!Parser"
application (Not completed to my satisfaction yet. Still has massive
shortcomings.)

Common.FmtCSV : This contains some simple generic value alignment
routines used to simpify the CSV dump code from the three data entry
tools.

Common.IOLib : If you've been following my programming for a while,
you probably already know about this one. It's a general purpose
abstraction and handling layer for dealing with file I/O. The idea
behind it is that, as long as you use the library calls, you never
need to worry about that dreaded CLOSE#0 screwing everything up. This
makes keeping track of files easy. It remembers the internal handles
and deals with internals like that, presenting you with a set of
single calls whether you're reading from a file or writing to it. You
just set the operation mode when you open the file. Full documentation
for it can be found in the Docs directory inside !MoriaDev.

Will get that missing CSV dumping code written today.

[Gazza]

Missing CSV dump code written and option has been re-enabled from the
main menu. As a bonus, I managed to write the BASIC equivalent of
monsters.c. This can be found as !DBMoria.Bin.Monsters in the
moriawip.zip download.

Downloads are up to date, I'm going to be away for a week, so won't be
able to continue during that time, but will be reading this thread
whilst I'm away.

[Gazza]

Started working on the Moria codebase again last Friday and found
another file full of data entry. Looks like I'll be writing a program
to get that little lot in. Probably more than one looking at the
nature of the datasets. Done a bit more with Misc2.c, though it's
nowhere complete and hasn't been uploaded yet.

Looks like I'm going to have to go through and re-hash the code that
deals with flags. Didn't properly understand it. That's about it this
time.

[Gazza]

Got a set of flag handlers written. This helps me sort out all the
flags stuff. Might, to some, seem overkill to have a set of FN/PROCs
to do this, but as a result I can reduce something like this...

tmp%=FNbbc_type_player_returndata(py%,"flags.status",0)
tmp%=tmp% AND (NOT PY_BLIND%)
PROCbbc_type_player_setdata(py%,"flags.status",0,tmp%)

to...

PROCbbc_type_player_setdata(py%,"flags.status",
0,FNbbc_type_clearflag(PY_BLIND%,FNbbc_type_player_returndata(py
%,"flags.status",0)))

So... Today I did most of the alterations, fixing up what I'd already
written to use these new handlers. Also has the bonus that if
something is wrong with what I'm doing, then I only need to change one
thing. Should be at Feltham with this little project on a couple of
floppies, so folks can see what's been going on. Won't be complete
though.

[Gazza]

Updated the server with the latest changes to moriawip.zip &
devtools.zip...

http://www.garethlock.com/acorn/moriawip.zip

http://www.garethlock.com/acorn/devtools.zip

Will probably zip up and stick the original C source and files here
too before ROUGOL in 9 days time.

[Gazza]

Finished off the rest of the flag re-factoring, got all the code
already written to use the new flag handlers, this is still quite
hacky at the moment with the main game logic calling directly into the
BBCType library, which up until now has been used only by the type
simulation code. Might add front-end routines to each of the types
that use flags.

The updated code can be found at http://www.garethlock.com/acorn/umoria/moriawip.zip

I've also uploaded the original source to UMoria v5.3 Patch Level 1,
which is what I've been porting.

This can be found at http://www.garethlock.com/acorn/umoria/umoria531src.zip

Enjoy... I'll be taking this all down to ROUGOL on floppies for anyone
interested.

[Gazza]

Continuing on with this... Got Misc2 finished, bar a couple of
routines that I couldn't decipher. Will have another look at these in
due course. Currently tackling all the data-sets in player.c. Creating
a program that dumps all this to a file called PyData with the rest of
the static tables. Coming across a subscript out of range error when
trying to READ all the data in. Have had several type mismatch errors
here too. Have a suspicion that I'm getting the data out of sync
somewhere. Will take a closer look at this and post an update once
I've had a chance to iron out the bugs in this bit and written the
replacement to player.c that will read this file in and munge it all
in.

[Gazza]

Now have a full PyData written after finding out that I was missing
half the spell table, so of course I was getting type mismatch errors.
DATA was out of sync. Largely got player.c re-written too. Just ran
out of time towards the end of the day to finish it off. Updates
already posted.

[Gazza]

Got a bit more done over the last couple of days. Mainly involving
myself in tidying up and streamlining the development tools that make
the files and their respective object init files inside !DBMoria.Bin.
Anyway, I should get these updates posted by the end of the week.

[Gazza]

Spent most of the day sorting out minor niggles with the development
tools. Re-Wrote some of the file I/O routines to use the array
handlers in the updated version of IOLib rather than the work-arounds
that I'd hacked up because the old IOLib ones started walking arrays
from 1 rather than zero. Prevented users from adding, cloning and
populating records beyond MAX_OBJECTS thus preventing stupid
"subscript out of range" errors. When I said these tools were crude, I
meant it.

In other progress, I've finished off conversion of main.c and started
wizard.c. Updated files not yet on server. I'll post here when I get a
chance to update them.

[Gazza]

Just managed to upload the changes. All files can now be reached from
here.

http://www.garethlock.com/acorn/umoria/index.html

[Gazza]

More work today on porting wizard.c. Not yet had a chance to upload
the changes.

[Gazza]

Much work done these last couple of days. Got wizard.c finished. Got
variable.c ported and started on recall.c. Written another tool to
create a file that is loaded in by the recall code containing all the
strings required.

What's even better, is that it's all available for download from the
usual location. http://www.garethlock.com/acorn/umoria/index.html ...

[Gazza]

Continued work on save.c. Added more robust code when checking for
read condition codes when calling IOLib quick_cint(), quick_cstr() &
quick_creal(). These only make sense when writing, so drop through
when reading. Added _setpointer() handler to player_type handling code
to approximate "m_ptr = py.misc", then "m_ptr -> fos" to access
"py.misc.fos". We just use...

PROCbbc_type_player_setpointer("misc")

Then we can use _returndata() or _setdata() in the usual manner, we
just don't need to specify "misc" all the time. Specifying a leafname
with the read/write handlers overrides that set by _setpointer(). I've
made all the player_type related stuff in save.c work in this manner
and will upload the current progress in the next couple of days.

[Gazza]

Still no fresh uploads yet, but getting on with porting save.c. Found
I can probably shave a lot of crap out of this down to the way I'm
managing the I/O with IOLib and just have one routine which both reads
and writes the body of the file (with helpers for the different object
handlers) and two other front-end routines which control user
interaction, one for reading and one for writing. Currently I'm not
using any encryption/protection on the save files, but will probably
implement some sort of XOR scheme like I did for Invaders a while
back.

I'm writing the values in the same order as those in the original
UMoria save files, but due to the internal format of BBC BASIC files
written with PRINT#, the resulting files won't be directly compatible
with those saved by the original C source. However, it should be
fairly trivial for someone with more knowledge of the inner workings
of the original file format written by the C source, how BBC BASIC
writes values to files using PRINT# and how I plan to implement
encryption/protection, which I will disclose once I've finalised
something, to write a short utility to convert between the two formats
if they so desire. Once I have something that works, I may even be
inclined to hack something up myself.

[Gazza]

Just a quick post this time. Got around to uploading the files. I
think the only one to have changed is moriawip.zip and this can be
found at http://www.garethlock.com/acorn/umoria/index.html

[Gazza]

No upload yet, but further progress on save.c. I think I've thinned
out the read/write logic, split I/O into managable chunks and created
a system whereby each chunk has a write handler and a matching read
handler. I've implemented read/write handlers for the protection and
the protection routines themselves. I've moved all the read/write
logic into one function and I think I've written most of the write
handlers. Just need to code the read handlers, tie in the UI routines
(The two entry-points from the main game) and handle open/close file
properly. Then tidy the whole lot up and that should be that file
ported. Though it's becoming more of a re-write than a port...

[use...@garethlock.com]

Finally getting to grips with save.c. As I suspected last time I posted, it's a complete re-write. Pretty much the same logic, just different protection routines. I've split save.c into two files now. "Bin.Save" is the top level read/write logic and UI routines, "Bin.SaveIO" is the low level stuff including the encryption handlers, open/close file stuff, header/footer/magic validity checks and handlers to write INTs, strings and arrays of said types while doing the encryption on the fly. Eventually I'll also have the individual object IO handlers here too.

File has been uploaded. Check out http://www.garethlock.com/acorn/umoria/index.html

[Gazza]

Finally got all the stuff in SaveIO written. That's all the object
read/write handlers and the protection code (this was there already
after the other day's session). Also tidyied up some of the remaining
logic in the original save.c port. Still got a whole lot of that part
of the logic to figure out though. Will get around to doing this next
time probably.

In other developments, I've patched a way of passing strings directly
to all the _setdata() type handlers without breaking existing code.
Will convert code to use this new method and assimilate the _setname()
handler code into _setdata() once I've spotted all the references. For
now the _setdata() code just points to _setname().

Changes uploaded to http://www.garethlock.com/acorn/umoria/index.html

[Gazza]

Removed all references to _setname() and assimilated this code into
_setdata() handlers. Still need to go through the typedef error
handlers and remove any messages & code relating to _setname() in
those. The files have been updated to include a full set of read
handlers at the logic level. A savefile can be read in. I do have the
write side complete now, although this last update has yet to reach
the server. There are a few things I'd like to tidy up and check
before I'm ready to release it. If anyone here can remember the game,
I need clarification on exactly how much data is written to a savefile
when...

1. The character completes the game.
2. Not completed the game, but dead.
3. Alive and well.

I think I've got the divisions right, but I'm not sure. Also, there
are a few other things which I'm struggling to figure out.

More news as it happens...

[Rick Murray]

On Sun, 25 Mar 2012 20:04:24 -0700 (PDT), Gazza
<use...@garethlock.com> wrote:

> More news as it happens...

You know, this might read better on blogger/blogspot or such, so you
could drop in screenshots and the like. Have you thought of
approaching it as a blog?


Best wishes,

Rick.

[Gazza]

On Mar 26, 12:05 pm, Rick Murray <heyrickmail-use...@yahoo.co.uk>
wrote:

Yeah... This was only intended as a temporary measure until I had the
time to do an index page, come progress report a la Acorn Invaders.
This has now been accomplished and all my progress posts have been
moved there. Future updates can be found at http://www.garethlock.com/acorn/umoria/index.html.
This topic can now be closed. I'll open a new one as and when I have
issues.

[Gazza]

I know I said this thread was closed, but I couldn't help bringing it
back to the top of the list. Much progress since last time as an
opportunity has arisen that allows me to work on it pretty much three
days a week rather than just one. Current status and more details can
be found at http://garethlock.com/acorn/umoria/index.html