Fast scrolling game howto, anyone?

[Chema]

Thanks Dbug! I will try to write something and provide some screenshots. About the loading screen just google for the loading screen of Uridium on the C64 and that's what I was thinking about... But better.

I tried to come up with an image of a ship resembling the player's ship and converting it with pipi, but results were horrible. I will try to gather my attempts and send them to you...

And I am not even sure what the problems could be when setting hires, loading the pic, then the game and then getting back to text mode. I guess I may be overwriting some hires memory when loading my data....

I had some feedback from my new beta testers and it was all very positive. The beginner mode seems to do the job quite well, for instance

[Dbug]

Thanks Dbug! I will try to write something and provide some screenshots. About the loading screen just google for the loading screen of Uridium on the C64 and that's what I was thinking about... But better.

I tried to come up with an image of a ship resembling the player's ship and converting it with pipi, but results were horrible. I will try to gather my attempts and send them to you...

Imo, the Spectrum title screen looks better
See here: http://www.ysrnry.co.uk/articles/uridium.htm

I could try to make an Oric version from the Spectrum one if you want, like Skooldaze, with I guess the font changed to Oricium instead of Uridium

Now, timing wise, you have to know that I'm going to be in holidays soon, but I will be mostly traveling in my camper, with only occasional access to internet, and I'm not sure I would enjoy pixeling on my 14" laptop instead of having the aperitif outside in the nature

If you would be fine with releasing the game in one month instead, that would give the time to do all the stuff, pictures, debugging, website, etc... without stress.

[Chema]

Something based on the speccy version is ok with me

I am going on vacation all August, with no access to the Internet (hopefully). Couldn't t you give me access to the web page, so I can edit content? I think you did that in the past, but I'm not sure if I ever used it...

Maybe lay down something preliminary, and let me upload the game and update links...

Well, as I am writing this, I realize that this may not be so simple, or even convenient to you, so if you think it's not worth it...

[Chema]

Still in the process of hunting some bugs spotted by beta-testers, as well as implementing some of their suggestions. I've made some good advances towards a final version.

One of their suggestions is something players will like:

Yep. An opportunity to directly re-start the last level in the same conditions the player started the last time.

I also corrected two stupid bugs: one with the synchronization of movements (which was creating horrible effects from time to time) and another one which prevented the game to run on an Oric-1.

Current version is 0.8, so I hope to have a final version in a few days.

[Chema]

We are preparing everything for the release! Last step is trying to integrate the loading screen. I have some doubts about how this could be done. The game is in text mode, so loading the pic after the game is not the best way to go. I might put two different parts in the tap, one with the title screen and then load the game, but that would prevent tap2cd to work correctly.

I can create an ultra fast loading version with the title screen before, such as I did with SkoolDaze, but that means having two different versions.

Decisions, decisions....

Stay tuned

http://oricium.defence-force.org/

[peacer]

I have clicked the link saying : " You can download the current version of the game here:" and failed with disappointment

Can't wait

[Chema]

I have clicked the link saying : " You can download the current version of the game here:" and failed with disappointment

Sure; it says "Coming soon", where "soon" means "whenever we can bundle it all"

[Chema]

Hi again.

I had to tweak a bit inside the program to make sure that no artifacts appear when loading with a graphic in hires being displayed. Basically loading data out of the hires memory and copying it after load.

This way we could have a Basic loader that switches to hires and loads the screen and then loads the game. This means, in the end, having a tap with three parts (loader, graphic and program). This is quite clean, but means that using tap2cd with it will be quite a nightmare., if it ever works. Of course I could try to prepare a pre-generated wav with turbo loading, though.

In addition, a different loader should be put to make the game load from disk. No problem, but the user won't be able to simply use tap2dsk to make the disk himself.

So basically I am not sure how to proceed here. Keeping three different versions is never easy. Another possibility is distributing the game as three different tap files (loader, screen and game) and let the user do as he wishes. But that would mean tweaking the loader or doing some work to make it load from disk.

I find no easy and clean solution, really. So any ideas will be appreciated.

[iss]

IIUC, here is my very quick idea: having one universal loader with correctly set name in tap header, when started, it checks for its unique name in 'last loaded program' buffer, if the check succeeded continue with tape loading routines, else switch to disk loading.
But probably the case is more difficult and I'm wrong....

[Symoon]

I'm not sure I understand the problem. Can it be summarized like this:
1- You want to avoid having both a TAP, fast WAV, and DSK version to distribute
2- you think multipart is a problem with tap2CD
3- the user should be able to make his own disk from the TAP file

For 2-, I think you know tap2CD better than most of us here. I didn't recall multipart TAP files were a problem with it?
For 3-, Tap2dsk manual says it can copy all the files included in a TAP file (and all the TAP files from a directory!) to a DSK file

So to me the solution is (not tested):
- indeed a loader, doing HIRES then testing if Sedoric is on => if so LOAD the files, else CLOAD them
- both files (HIRES then DATA)
- the whole 3 appended as a single TAP file
- maybe the trick of starting the HIRES screen 1 byte earlier holding a RTS, then saving it in AUTO mode, can help with ROM 1.0

I don't think anything would go wrong there?

[Symoon]

- indeed a loader, doing HIRES then testing if Sedoric is on => if so LOAD the files, else CLOAD them

Ah, the only problem with this is that you couldn't load the tape from an Oric running Sedoric: the loader would load from tape and then search the files on disk instead of tape.
So the real test would be to find a way to detect from where the loader has just been loaded (tape or disk)

[Chema]

I found many many issues trying to produce a release today...

I have a really nice picture from Dbug and tried to bundle something. Just 10 minutes, I thought. Alas! I was wrong.

It seems that pictconv options o1 and o0 are swapped, and it took me quite a lot to find so. Using o1 is the one which produces the screen data without a loader.

Once I found this, I noticed that CLOADing the pic, made the Oric halt in the end. I turned out that adding an additional byte (I put a zero) with an hex editor solved the problem.

I managed to make a loader which loaded everything using CLOAD"SCREEN.TAP", etc. Works nicely if you have three different tap files (which, btw, can be made fast wavs, but forces the user to insert or reproduce all of the wavs in turn, which is a mess).

To make it work I changed the loader (removing the .TAP in the CLOADs) and concatenated the three tap files. Hey, that works! fine. Next I tried tap2cd. It hanged. Again problems.

And, to my surprise, the concatenated tap did not work in an Oric-1. The program got back to basic after loading the screen, without CLOADing the actual game.

Well, at least I was able to produce a dsk which works! I don't need an extra loader. Just put the screen and program in the disk and use the INIST sentence to do the work. This was the only good news today.

Can't believe it. I am leaving on holidays tomorrow, so if I am not able to produce something soon, the release will have to wait until September or so.

Sorry, maybe I am doing something completely wrong, but I don't find what it can be...

[Chema]

Sometimes all that is needed is some ranting, a rest doing other things, and a retry of 5 minutes.

Well I finally produced the tap, wav (fast) and dsk versions. The tap file contains three blocks and it is perfectly converted to fast wav by tap2cd (don't know what I did the last time, but probably related to the need to add an extra byte to the tap generated with pictconv). The dsk version contains two files (screen.bin an oricium.com) and the game autoloads from the INIST command.

And I can create all of them with a simple .bat file, which simplifies things...

The only issue I have now is that the BASIC loader is not working on the Oric-1. I think I recall something, but not sure. The symptom is that after loading the picture it returns to the Ready prompt instead of continuing running the loader. Simply typing (blindly, as ink and paper are black) CLOAD"" <RETURN> after the picture is loaded and you get the cursor back loads the game and runs perfectly.

I know I can do ugly things such as POKING here and there, but is this a known problem with ROM 1.0? Is there a simple, elegant, solution?

I also have a further question. I can release the game as it is now (including this bug). You could consider it as a 'pre-release'. Most people will play it with emulators, Atmos or machines with Cumulus, so not a big deal. I can then collect all the bugs, suggestions, whatever and, in September, I can prepare a new release 1.1 solving all of them, and maybe including a new version of the loading screen (I know Dbug did a huge effort to give it to me yesterday evening, and he might want to work on it more... or not; it is perfect as it is).

The alternative is waiting until I am back from vacations and have time to dedicate to the game... so wait until September, but directly with a much more polished version.

And I have to make the decision now as I have a lot of things to prepare for my holidays

[Symoon]

The only issue I have now is that the BASIC loader is not working on the Oric-1. I think I recall something, but not sure. The symptom is that after loading the picture it returns to the Ready prompt instead of continuing running the loader. Simply typing (blindly, as ink and paper are black) CLOAD"" <RETURN> after the picture is loaded and you get the cursor back loads the game and runs perfectly.

I know I can do ugly things such as POKING here and there, but is this a known problem with ROM 1.0? Is there a simple, elegant, solution?

Chema I think you're a bit tired

maybe the trick of starting the HIRES screen 1 byte earlier holding a RTS, then saving it in AUTO mode, can help with ROM 1.0

[Chema]

Chema I think you're a bit tired

maybe the trick of starting the HIRES screen 1 byte earlier holding a RTS, then saving it in AUTO mode, can help with ROM 1.0

Certainly I am... Okay now I know how to solve this. Pity pictconv does not provide this option

Well anyway it will have to wait till the next release, I'm afraid.

/me feels silly...