Expanding the range of QL Adventures

[omega]

Example images:
Hi-res



Lo-res


Mixed


Converted files for QL [rename TXT to ZIP]
http://files.omega.webnode.com/20000035 ... ns_zip.txt

Cristian, thanks for sample images. I will post it as well.

[tcat]

Hi All,

Aurora seems also an excellent platform, stretching the graphics limit while keeping a tie of compatibility to the standard QL.

EDIT now also catching up on the latest post, astonishing graphics, hey how you do it?

I learnt from Andrew Pennel's book, even normal QDOS has a few routines accepting screen{1,2} for their channel parameters. We already know that calling IPC is perfectly safe without systems vars.

I was thinking that a real game code may extend around this loop,

Code: Select all

; Now two vram{1,2} screens begin flipping
; by system at 50/60Hz screen refresh rate

loop     bra.s    loop

with either:
[a] still interlaced graphics
drawing an update in background screen, then flipping it to front on some user interaction

But say, If we kept a copy of the most critical sys vars, at the top video line/s (x 128 bytes), could we play some tricks by calling even more QDOS Traps?

NOTE
Perhaps one or two garbled video lines, would not spoil the user perception of animation too much, especially on CRT based monitors. I guess we need that CRT Luminiphore to perceive more colours anyway, or not?

Many thanks
Tomas

[omega]

At what point do we need a QDOS for an adventure game?
- keyboard entry
- print characters on the screen
- disk operations

Is there anything else?

Keyboard entry works fine without sysvars. Print screen routines can be written independent on ROM and Qdos.

In case of disk operations, I would suggest following:
1. disable interrupt
2. switch screen 1, clear graphics
3. revert back system variables
4. perform disk operations (load, save...)
5. re-establish dithvide (load gfx from memory, sysvars, interrupt..)

What are you thoughts about it? Does the ported game engine for Level 9 adventures require QDOS?

[omega]

I don't want to spoil this thread with too many images... Here are a few of them definitely.

Hi-res


Dragon's lair - source image is in high resolution, very wide. This is cropped section of source image, to keep details I used hi resolution. Not too bad.
Street fighter image is bloated with details of individual characters. Details would be lost in low-res mode, on the other hand - hi res keeps details but colors are lost... Bad picture.
TombRaider picture is quite well converted due to good match of source image colors with hi-res palette. Green, red, white, black works well in this picture and therefore dithering looks nice.

low-res


Fantastic four looks OK, ordered dithering helps to keep image clean even at low resolution

mixed


Prince of persia is very good example. This image will look good also in low res mode.
Star trek - source image has kind of wanished colors, ordered dither and a bit of pre-processing helped to boost colors.

dithvide files
http://files.omega.webnode.com/20000063 ... s3_zip.txt

[RWAP]

Some amazing imagery there - well done - it will be interesting to see how we can convert the Level 9 images.

I have found some zip files containing Level 9 games (in both ADF Amiga Disk format and .dat files ready for use with the Level 9 interpreter) at :
http://www.filfre.net/tag/level-9/ (search for zip)

[omega]

In response to Tomas, here are some ideas about display concepts.

Different hi-color display concepts

1. Software blitter
===================
This concept might be useful for fast machines (GC, SGC). In principle screens are pushed to videoram using fast software blitter. This software blitter shall move graphics from buffer to videoram at 50/60Hz.
Benefits:
* OS compliant
* Machine independent
Disadvantages:
* Even black QL can do this, yet window has very limited size
* SW Blitter consumes significant amount of CPU time (black QL) - game response might be ifluenced or too slow.

Method:
* link blitter routine to interrupt polled list. [Ideally blitter shall be the very first task that OS will execute].
* blitter shall be written in a way that copying to screen shall be always ahead or always behind of TV Ray. Crossing TV Ray with currently copied data will result in tearing effect.
* Fast mem copy routine is requied for black QL [Rich's MOVEM]

2. HW Flipping of Screen 0/1
============================
This concept will flip screen 0 and screen 1 every interrupt. It can be used for Low-resolution or High-resolution high color modes.
Benefits:
* CPU can focus on main program execution. Hi-color display does not consume CPU time
Disadvantages:
* OS not compliant.
* It is not possible to use all QDOS functions while using hi-color mode (system variables in screen 0)
* All screen access routines (PRINT, Cursor, clear screen...etc) shall be writing data to BOTH screens

Method:
* save vars, supervisor mode, link flipper to polled list
* link flipper routine as single item in interrupt polled list.
* In case of needing QDOS, interrupt, sys.sysvars shall be recovered to initial QL state.

3. Mixed mode/split screen
==============================
This mode allows to split display to two parts - image area and text area.
* image area holds image in dithvide low, high, mixed mode (or simply native QL low res or high res)
* text area holds adventure game text output - high res mode.
Benefits
* best use of QL's display possibilities
* most flexible display mode for game(s) (hi-color, hi-res)
* screen access routines written for one screen only
Disadvantages
* OS not compliant.
* CPU has to be synchronised precisely with TV Ray
* CPU time is limited (e.g. 50% in case of 50% split screen).
Method
* save vars, supervisor mode, link flipper to polled list
* link flipper routine as single item in interrupt polled list.
* once display of image area is finished, game engine can be executed.
* In case of needing QDOS, interrupt, sys.sysvars shall be recovered to initial QL state.

I hope it is a bit clear.

[Cristian]

I don't want to spoil this thread with too many images... Here are a few of them definitely.

Impressive results! The Street Fighter details quality is so high! Unfortunately the color range of source image was too "red" therefore we can't get a very multicolour result.
Obviously from native low-res pictures (Prince of Persia) we can get the best results, but I'm impressed also by Tomb Raider and Fantastic Four!

[vanpeebles]

looks amazing

[tcat]

Hi,

EDIT
I like this mixed method, as seems simple to follow,
* save vars, supervisor mode.
* link flipper routine as single item in interrupt polled list.
* once display of image area is finished, game engine can be executed.
* In case of needing QDOS, interrupt, sys.sysvars shall be recovered to initial QL state.

Also not all graphics need be interlaced. H/W flipping could also be useful for smooth sequence animations, flip can be done every second or so, or on user interaction, while we can draw in the inactive screen.

Does the ported game engine for Level 9 adventures require QDOS?

I believe yes and quite often, this is a guide by the author on porting.
https://github.com/SinclairQL/level9/bl ... orting.txt

Most I/O functions work on QL as generic, because they have equivalent in C68 `libc_a'.
You may try running QDOS binary here, with `knork1_dat', it works.
https://github.com/SinclairQL/level9/bl ... dos/level9
(NOTE need dataspace 48400, and set executable header)

For Atari GEMDOS/MS-DOS, also work as generic, they both borrow from CP/M, and they have same file I/O, floppy format, and probably many underlying structures identical.

Graphics is different, I think we probably need to implement these.

Code: Select all

void os_graphics(int mode)
{
}

void os_cleargraphics(void)
{
}

void os_setcolour(int colour, int index)
{
}

void os_drawline(int x1, int y1, int x2, int y2, int colour1, int colour2)
{
}

void os_fill(int x, int y, int colour1, int colour2)
{
}

void os_show_bitmap(int pic, int x, int y)
{
}

Game graphics is enabled by typing #graphics at the `level9' prompt.
Text mode by #text.

As there is not a really big difference among Atari/DOS/Amiga ports, code is almost same size for them.
For black standard `QL' code size seems fairly big, because code is too complex for it.

Built w/ `bitmaps.o'
file size: 79810 bytes
data space: 47936 bytes

Built w/o `bitmaps.o'
file size: 58416,
data space: 48400 bytes

Tomas

[tofro]

You can even display mixed text & graphics if you simply make sure you print the identical text into both screens

Tobias