Remake of those old Loading screens

[+Stephen]

Well,

 

but then you have a minimum of 2 files on the disk: XBIOS.COM and the program of your choice (and you also require a loader). What CreatureXL and I would like to have is XBIOS+Game program as one single file (e.g. appended together). I know this does not work yet, but I just tried it here anyways: 1) changed the RUN adress of XBIOS into an Init adress, 2) appended Pole Position X to it and 3) put a Basic off, coldstart routine and black screen routine in front of Xbios. The goal I wanted to reach was that Xbios loads and inits, then Pole Position X gets loaded and runs (just as an example program, could have been any other game program). Alas, its like I thought, Xbios still shows the menu screen and does not execute the appended program...

 

Check this (non-working) example to see what I mean:

test.zip

 

It would be very cool, if Xbios could work as a mini-Xbios *without* the menu screen, just loading and executing one (or more) appended file(s)... -Andreas Koch.

 

From post #35

ordinary formated disc or atr, AtariDOS filesystem family e.g. MyDOS, up to 16MB.

any boot loader or dos (or dedicated 2-sector bootloader) to run xBios. save your program as "xautorun" or "Menu" will appear.

if you want to boot or I/O from CAR or RAMDISK there is xBios driver for this.

Is that what you needed to do?

[+CharlieChaplin]

No Stephen,

 

I wanted to have XBIOS.COM and a ML-file as a single/stand-alone file (appended together), e.g. name the file LN2.XEX which stands for The Last Ninja 2 and consists of a) Xbios, b) LN2 titlescreen and c) LN2 program.

 

Alas, this is not possible, as XXL already told me. The only possible way to load a ML file, without the menu to appear is to name it XAUTORUN (so you have at least 2 files on a disk: Xbios.COM and Xautorun, not a single file).

 

Greetings, Andreas Koch.

Edited March 13, 2013 by CharlieChaplin

[+Stephen]

Ah - sorry for the misunderstanding.

[Tezz]

That would be nice Andreas but it's not really feasible with different storage solutions and dos varieties

[Tezz]

I've now identified and fixed the issue with the Boulder Dash II 25th Anniversary loader this afternoon.

 

The disk image is attached.

xbios_bdii.atr

[xxl]

realtime 50fps kefrens during loading/writting data to file...

 

[Creature XL]

That would be nice Andreas but it's not really feasible with different storage solutions and dos varieties

 

That's sad but understandable. At least with my small knowledge of loading stuff directly from disk.

 

 

@Andreas:

Thank you for explaining "my" problem more eloquently

[sack-c0s]

Am I right in thinking you could update a double-buffered displaylist during this time? I can see it being possible to create the illusion of a seriously heavy workload whilst loading (repointing the screen memory to create the impression of moving large bitmaps, scaling, barrel-rotation of logos, etc. for example).

[Tezz]

Am I right in thinking you could update a double-buffered displaylist during this time? I can see it being possible to create the illusion of a seriously heavy workload whilst loading (repointing the screen memory to create the impression of moving large bitmaps, scaling, barrel-rotation of logos, etc. for example).

Yes, that should be possible

[Tezz]

Continuing with more games from Zeppelin, I started preparing Jocky Wilson's darts compendium a couple of weeks ago. As I was taking it apart it was apparent that it was quite poorly written and had numerous bugs and issues so I set about patching it.

 

So, this is what’s been done:

 

added : loading picture

replaced : new Jocky darts play scene in colour

replaced : new dartboard scene with colour scoreboard and players names highlighted clearer

fixed : pre-existing issue : dma and sprite garbage between scenes

fixed : pre-existing bug : darts sound fx incorrectly implemented

fixed : pre-existing bug : the game over music does not init and play correctly

fixed : pre-existing bug : Jocky's previous darts still showing for a frame when returning to the scene

fixed : dart play delay timing

 

There were a few things that I didn't do ...

 

The dart was intended to have a soft sprite underlay but it works reasonably well enough without it so I don't think it's worth taking up anymore time implementing that.

 

There's possibly another pre-existing bug whereby Jocky's dart throw goes into a loop for a short time, I couldn't replicate this after much game testing so it was either something that occurred whilst I was pulling it apart or it's a bug that occurs infrequently.

 

The game "scram" goes beyond 3 digits and shows symbols and garbage in the scores

 

 

I’ve added the game onto an extended density disk image along with the other Zeppelin titles.

It's not the greatest of titles but at least now it’s better presented.

zeppelin_ed.atr

Edited March 29, 2013 by Tezz

[José Pereira]

Great!

[+therealbountybob]

This is a nice project / thread

 

I guess I'm going to need some more floppies for my 1050 though - assuming these are intended to work on real kit too?

 

It would be even better if any improvements to gameplay could be made or PAL speed adjustments etc

 

keep up the good work guys

[José Pereira]

Del.

Edited March 30, 2013 by José Pereira

[José Pereira]

Tezz:

On the in-game screen with Jocky throwing darts are you still using the original bitmap GR.15 or did you change to char-mode GR.12 to have one more colour with the PMGs?

(you're still exactly using same pixelssame bit-pairs of the original?)

Edited March 30, 2013 by José Pereira

[Tezz]

Tezz:

On the in-game screen with Jocky throwing darts are you still using the original bitmap GR.15 or did you change to char-mode GR.12 to have one more colour with the PMGs?

(you're still exactly using same pixelssame bit-pairs of the original?)

Hi José, the new ingame screen is mode 4 (Gr.12) and was repixeled from the c64 gfx keeping some of the changes of the original A8 gfx. Ian Copeland used bitmap modes for everything including the "text" titles and menus in all of his games as far as I've seen.

[José Pereira]

Yes that's because back they always go into bitmap and never used charmode multiple charsets.

A static screen 40Bytes wide it's around 8KBs so the same sized screen in charmode 24charlines and 1charset per 3charlines it's exactly the same.

And if the text/numbers part one single/alone there would be even less charsets.

 

Tezz, there you're doing G2F like 40Bytes wide screen 3charlines=1charset?

Edited March 30, 2013 by José Pereira

[Tezz]

A static screen 40Bytes wide it's around 8KBs so the same sized screen in charmode 24charlines and 1charset per 3charlines it's exactly the same.

That would be the case if every single char on every row was uniquely defined. It's usually far less.

 

Tezz, there you're doing G2F like 40Bytes wide screen 3charlines=1charset?

The raw bitmap occupied 8kb with an additional 704 bytes for the dart throwing animation so 8896 bytes just for the raw data. Then there's the procedures and tables to prepare and update the bitmap display.

 

The new display is 40 byte wide char mode 4 with 3 fonts (+ one partial @ 96 bytes), screen ram is 920 bytes, compressed pmg and char table data is 528 bytes, the DLI program is 749 bytes (although that could be smaller) so 5365 bytes in total.

[xxl]

xBios: new version.

new variables available to the programmer

[José Pereira]

Always thought and never get how:

On Gauntlet first/presentation screen GR.15 Bitmap 4colours how they got those DLIs scrolling rainbow on Gauntlet logo letters?

Black it's [00] BACKGROUND Register colour so no way to have expandable width PMGs there following the letters contour.

Even if I think the screen in charmode the rainbows can't be PF3 because there will be clash in some parts whatever wich of the Browns I choose as PF2.

How?

Edited March 30, 2013 by José Pereira

[Tezz]

The Gauntlet title is mode 4, the lightest colour #$28 is pf2 with the logo dli pf3

[Tezz]

xBios: new version.

new variables available to the programmer

Great, thanks I noticed your update at AOL.

[+CharlieChaplin]

Great !

 

@Tezz @Jose: And now some re-painting of the gfx in The Pawn, Jinxter and Guild of Thieves, please...

 

-Andreas Koch.

Edited March 30, 2013 by CharlieChaplin

[José Pereira]

@Andreas:

I thought that when the release of Rasta Converter.

Probably the best way to go? It would be automatic picture conversion but, on if seeing things better it maybe will not be faithfull conversions because some not on the original horizontal scanlines may come.

I downloaded some C64 screens of that games in my disco waiting me... But like I said here some times I am not 'a must' on these loading/graphic adventures but could try.

If we use the C64 screen at the size as it's on A8 then I wouldn't see any problem.

Without the need of re-writing it's only in those Level9/Rainbird that has gfxs on A8.

I can accept that any here send me a P.M. With all the C64 screens of that ones that aren't 'Text only' on A8 you can find but no promises.

Tezz seems to have so many things in hands that it would be very good if more guys from the coding side want to join.

 

 

P.s.- I would be more interested in a Defender of the Crown/Cinemaware productions onto A8 because it would be more 'my way': in nice coloured screens I can still think in the ways to have other/different colours on some moving things.

But these are writing new games and if one day I post here something they sure become just one(s) more to me trying to find "Who will do the code?".

[Synthpopalooza]

Jose: Do you have any of those C-64 screens in their native koala format? And if you do, could you send me some?

 

I'm trying to come up with an algorithm for converting C-64 koalapad pictures into .IPC (Gr. 12+10) pictures. I've already come up with palette settings in PCIN that duplicate almost exactly the Commodore 64 16-color palette, so I think this may be possible.

 

I did a chart showing the usage of C-64 colors using the 34-color PCIN palette. The idea is, you should be able to read two pixels from the c-64 bitmap, find the best match from one of the nine PCIN color groups, and do the conversion. It also helps that the PCIN bitmap layout is identical to how the c-64 lo-res bitmap is laid out (i.e. by 4x8 char cells)

 

[José Pereira]

Hi.

Another one from me today... As you can see I've been very busy last Night (then I had to stop The Pawn but I'll return with it tomorrow):

Nodez is a very active one on adding Loading screens into the games files using the Raster Converter at ataiOnline.

One of is latest ones was Aztec Challenge but because it's done in rasta converter it's resized to 2:1 ratio and lots of DLIs changes it's impossible to use it during loading (it shows the picture but then you have to click on a key and then the game continues to Load and Run).

 

 

When I saw that picture of the C64 version 8that is indeed a tottally diferente looking version because it's 'from behind' in Space Harrier same type) I just saw that we could have it exactly same way as C64 but with our good Palette.

Because I extracted the chars and they were only 64chars on screen we could have it in GR.0 Char Mode just 1charset or in Gr.8 Bitmap Mode and no DLIs (just PMGs used eachone only a single time):

 

 

 

As you can see the Borders are diferente coloured because in most of the situations I really like to use the oportubity we have in Hi-Resolution Modes to have a diferente colour on the Borders.

Hmm... But there's something there that could look better... And so I just add these lines 'bordering' the screen:

Now I am happy, REALLY HAPPY!...

 

 

 

@ Tezz or any other: If you want to add this one to the A8 version of Aztec Challenge remembre that it's just 'replace' the original screen with this one because here we don't need xBios for Nothing:

AZTEC CHALLENGE A8 Loading Screen.zip

So the game would Load and run like the original old one.

Edited May 8, 2013 by José Pereira