Expanding the range of QL Adventures
Re: Expanding the range of QL Adventures
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.
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.
Re: Expanding the range of QL Adventures
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,
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
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
[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
Re: Expanding the range of QL Adventures
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?
- 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?
Re: Expanding the range of QL Adventures
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
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 Master
- Posts: 2840
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Expanding the range of QL Adventures
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)
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)
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
Re: Expanding the range of QL Adventures
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.
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.
Re: Expanding the range of QL Adventures
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.omega wrote:I don't want to spoil this thread with too many images... Here are a few of them definitely.
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
- Commissario Pebbli
- Posts: 2822
- Joined: Sat Nov 20, 2010 7:13 pm
- Location: North East UK
Re: Expanding the range of QL Adventures
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.
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.
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
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.
I believe yes and quite often, this is a guide by the author on porting.Does the ported game engine for Level 9 adventures require QDOS?
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)
{
}
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
Re: Expanding the range of QL Adventures
You can even display mixed text & graphics if you simply make sure you print the identical text into both screens
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO