News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Hero Quest CPC Plus CPR with music?

Started by viddi, 17:17, 16 October 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

MacDeath

#50
Equivalent to 320x240 could be nice actually... (160x240 on Mode0 then) or even some PCW-like 360x240 equivalent could work well (PCW allows for 720x256 mode2). But extra "overscan/fullscreen) but will eat extra RAM used as VRAM, especially if you go for double buffering... still quite manageable if you get at least 128ko RAM and game engine and main assets stored into 512ko Cartridge/ROM solution... or X-MASS+extended RAM configuration as many/most users own these days (and emulator can do them as well).. let's live in 2025, not 1985 anymore !

Mode1 can be better than expected, fine text and detail work well too.
See Head Over heels for a proper use of it.

Yeah getting limited to speccy48's 256x192 sucks when you can expand into 320x200 or 360x240 or 394x256 or whatever (better to play it safe so keep a bit of border though)... Also they often fail to put a smaller font and keep to speccy like 8x8 characters letters, while some compact font/lettering, even in 3 colours, is fine and allows for more informations displayed on screen...

Good exemple : Black Land from Bollaware. Looks like 360x200 to me... (not sure, should check this)
not sure the game is that great to play but it shows the technical possibilities for Isometric RPG on CPC with extended specs and display.

CPC with 512ko ROM and 128ko RAM and floppy/HxC save and extra datas/campaign/maps multiload option combo may provide a game with 16bit system level  deepth. Would be like some game on CGA PC, yet on a CPC.
or CPC with 512ko RAM and any modern mass data storage solution.

keeping to mode1 and 360x240 resolution would be great as it would enable a PCW port.


Really, Heroquest got good reviews in its time because it was a somehow faithfull adaptation from the boardgame but honestly it was coded with feets by someone who couldn't know better about the CPC. Shameful shameful shitful engine and painfull to play even in the 90s, the man thought he was still coding on a spectrum ZX81 or what ?

abalore

Quote from: MacDeath on 22:32, 19 March 25Equivalent to 320x240 could be nice actually... (160x240 on Mode0 then) or even some PCW-like 360x240 equivalent could work well (PCW allows for 720x256 mode2). But extra "overscan/fullscreen) but will eat extra RAM used as VRAM, especially if you go for double buffering... still quite manageable if you get at least 128ko RAM and game engine and main assets stored into 512ko Cartridge/ROM solution... or X-MASS+extended RAM configuration as many/most users own these days (and emulator can do them as well).. let's live in 2025, not 1985 anymore !

Mode1 can be better than expected, fine text and detail work well too.
See Head Over heels for a proper use of it.

Yeah getting limited to speccy48's 256x192 sucks when you can expand into 320x200 or 360x240 or 394x256 or whatever (better to play it safe so keep a bit of border though)... Also they often fail to put a smaller font and keep to speccy like 8x8 characters letters, while some compact font/lettering, even in 3 colours, is fine and allows for more informations displayed on screen...

Good exemple : Black Land from Bollaware. Looks like 360x200 to me... (not sure, should check this)
not sure the game is that great to play but it shows the technical possibilities for Isometric RPG on CPC with extended specs and display.

CPC with 512ko ROM and 128ko RAM and floppy/HxC save and extra datas/campaign/maps multiload option combo may provide a game with 16bit system level  deepth. Would be like some game on CGA PC, yet on a CPC.
or CPC with 512ko RAM and any modern mass data storage solution.

keeping to mode1 and 360x240 resolution would be great as it would enable a PCW port.


Really, Heroquest got good reviews in its time because it was a somehow faithfull adaptation from the boardgame but honestly it was coded with feets by someone who couldn't know better about the CPC. Shameful shameful shitful engine and painfull to play even in the 90s, the man thought he was still coding on a spectrum ZX81 or what ?


That's 336 x 192 which still fits in a single buffer. We can say it's a "panoramic" mode 1. It gains 2 more chars in width and lose 1 char in height. I also takes advantage of 128 bytes more than the "normal" mode 1, given that you don't use the hidden video buffer bytes for other purposes. For me the main problem of 4 colours is that doesn't allow a good separation of background and foreground and it's stressing for the eyes. I'll give a try to mode 0 and then we'll see.

Regarding memory, for me is a must that it can run on 64k to be compatible with stock GX4000

andycadley

If you're targeting the GX you could have 168*192 in Mode 0 for the game area, which fits in 16K and can thus easily be double buffered if required and then use a second, single buffered, screen area for the status panel area (using hardware splitting). And, of course, you'd have the possibility of using sprites either for overlays or for characters with more colours (though you'd have to clip them in software).

Egg Master

On GX4000 you don't require a double buffer to display something like a 384x256 "zoomed" display.

andycadley

Quote from: Egg Master on 19:24, 20 March 25On GX4000 you don't require a double buffer to display something like a 384x256 "zoomed" display.
You don't need it, but you might want a double buffer if you're having to draw isometric graphics off screen rather than chasing the raster. Especially because you're less likely to be using sprites for everything.

MacDeath

#55
Quote from: abalore on 17:02, 20 March 25For me the main problem of 4 colours is that doesn't allow a good separation of background and foreground and it's stressing for the eyes. I'll give a try to mode 0 and then we'll see.

Regarding memory, for me is a must that it can run on 64k to be compatible with stock GX4000
If background uses 4 inks and foregrounds only 3 (as in head over heels) trust me the "separation" can be effective... but yeah, not everyone is fan of mode1.

GX4000 ? for a dungeon crawler  with character building, campaigns and a dire need to save characters and stuff and campaign progression ??
ok guess the GX4000 can generate some long hexadecimal code to be entered later, after all...  :laugh:


Ok, I tested on winape, can't save my heroes, it this normal ?

dthrone

Quote from: MacDeath on 13:17, 19 March 25BTW, some from scratch modern version could stick with Heroquest board game, or go for the Advanced Heroquest or even Warhammer quest board games later released by Games Workshop, yet the original Heroquest is nice because of its simplicity and  had many supplements, not jsut in computer game versions...
Same with SpaceCrusade, I would love some Eldar Attack option or even playing with an Ork warband as was offred in some whiteDwarf supplement (or Terminator or scout space marines quads...

If someone were to do some modern Heroquest/SpaceCrusade project, I'm quite into those games and Warhammer in general (both fantasy or 40k) and even other games such as SpaceHulk could use the same graphic engine.
Would love this, would do myself, if there wasn't 100% chance of a cease and desist :laugh: :-X   They're worse than Nintendo ???
SOH Digital Entertainments

MacDeath

I checked Advanced Heroquest, which is a different game in fact, far more complexe, but this could do a wonderful rogue-like experience if faithfully ported, yet to be honnest I really wonder whether this wouldn't be a too big bite for an 8bit system.

C64 scener managed to get some Eyes Of the Beholder ported on C64, but it needs a souped-up C64/128 actually.

Those pen&paper/boardgames RPG could need a massive database or charts, rules, logic and assets to be handled somehow, but 8 bit computer with "hard-disk-drive" equivalent (X-MASS...) added with some other extra RAM or even ROM, and turn-based engine could probably manage this quite well enough.

abalore

Quote from: MacDeath on 22:17, 20 March 25
Quote from: abalore on 17:02, 20 March 25For me the main problem of 4 colours is that doesn't allow a good separation of background and foreground and it's stressing for the eyes. I'll give a try to mode 0 and then we'll see.

Regarding memory, for me is a must that it can run on 64k to be compatible with stock GX4000
If background uses 4 inks and foregrounds only 3 (as in head over heels) trust me the "separation" can be effective... but yeah, not everyone is fan of mode1.

GX4000 ? for a dungeon crawler  with character building, campaigns and a dire need to save characters and stuff and campaign progression ??
ok guess the GX4000 can generate some long hexadecimal code to be entered later, after all...  :laugh:


Ok, I tested on winape, can't save my heroes, it this normal ?
In physical edition I can save the data in the cartridge itself even on a GX4000.

RedAngel

#59
The loading screen looks very good but I would prefer it with more vibrant colours, and if it is a cpr version I would use the Plus/GX4000 palette. Here you are some options, the first one in classic CPC colours.

It is very difficult to improve the game graphically in mode 1 if you can´t use the four colours everywhere. I have made a mock-up with a different palette, using another colour for shading in the area outside the game and I have arranged some icons.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.

Egg Master

Well... I much prefer the colours Abalore chose. More readable.

RedAngel

Quote from: Egg Master on 12:45, 23 March 25Well... I much prefer the colours Abalore chose. More readable.
I suppose you refer to the upper part that has dark blue characters in a black background, yeah there is not enough contrast there, I don´t know if it is possible to paint a light colour rectangle and print the characters in dark blue... 

abalore

Quote from: RedAngel on 12:25, 23 March 25The loading screen looks very good but I would prefer it with more vibrant colours, and if it is a cpr version I would use the Plus/GX4000 palette. Here you are some options, the first one in classic CPC colours.

It is very difficult to improve the game graphically in mode 1 if you can´t use the four colours everywhere. I have made a mock-up with a different palette, using another colour for shading in the area outside the game and I have arranged some icons.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
Quote from: Egg Master on 12:45, 23 March 25Well... I much prefer the colours Abalore chose. More readable
Well, to be honest the colours have been chosen by TotO, with the only limitation that color indexes need to give a good result in a green monitor. Using Plus palette is not an option for this game since it's mandatory for me to work in all models and the patches don't allow much room for adding conditional code.

Anyway, this version is ancient story already, I'm working in a mode 0 version coded from scratch. Everyone is invited to mock graphics for it!

viddi

Any chance to get a "final ancient" version with better menu font colours? ;)

abalore

Quote from: viddi on 20:11, 23 March 25Any chance to get a "final ancient" version with better menu font colours? ;)
Yes, that may be the last change I made before final release.

viddi

Quote from: abalore on 20:27, 23 March 25
Quote from: viddi on 20:11, 23 March 25Any chance to get a "final ancient" version with better menu font colours? ;)
Yes, that may be the last change I made before final release.
Awesome! :)

MacDeath

#66
Quote from: RedAngel on 12:25, 23 March 25The loading screen looks very good but I would prefer it with more vibrant colours, and if it is a cpr version I would use the Plus/GX4000 palette.
if there are only 4 colours on screen, I don't find PLUS palette to be very useful actually.
As said before, better to have more contrast instead of 4 different shades of medium browned-greyish... why try to look C64-ish-yurkish..?


Else I have a few question concerning this hack...
Is it somehow possible to edit the tileset ? And if so, why wouldn't "grey" be usable by those background tiles  (floor and walls)?

I checked via winape, found the floor tiles and put some grey, when I refresh (switch to next hero) the tiles feature some grey zones I edited.
The trick is that those floor tiles are cut into slices of different width and height hence difficult to find via the find graphics option.

slices :
8 bytes x 5 pixels
10 bytes x 4 pixels
12 bytes x 8 pixels
10 bytes x 4 pixels
8 bytes x 3 pixels

funnily they are mostly 2 colours + grey/transparency... when the basic floor tile overlaps another one on its borders, it may creat pixels in light Cyan
if dark blue + dark blue >> dark blue
if Dark blue + light Blue > light Cyan
If anything + Grey >> stays the same... not sure if I am clear... but I understand myself anyway.

As those tiles are background, Grey not overlapsing other tiles would then stay grey (as per the back-background)
Sprites are unaffected by walking on grey tiles

IMO it was jsut lazyness from coder that prevented grey to be used by background tiles, but I may be wrong anyway

abalore

Quote from: MacDeath on 21:10, 24 March 25
Quote from: RedAngel on 12:25, 23 March 25The loading screen looks very good but I would prefer it with more vibrant colours, and if it is a cpr version I would use the Plus/GX4000 palette.
if there are only 4 colours on screen, I don't find PLUS palette to be very useful actually.
As said before, better to have more contrast instead of 4 different shades of medium browned-greyish... why try to look C64-ish-yurkish..?


Else I have a few question concerning this hack...
Is it somehow possible to edit the tileset ? And if so, why wouldn't "grey" be usable by those background tiles  (floor and walls)?

Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparent

MacDeath

#68
Quote from: abalore on 21:29, 24 March 25Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparent
check again my previous post (I heavily edited it)
Yeah Grey is used for transparency and floor tiles use this for the "corners" but it can work as use-able colour too, just for those floor tiles and back-walls tiles I guess (because they are put over a grey background...) provided you put the grey on zones which won't then overlap with other floor/walls tiles.

Wouldn't be usable for the sprites (heroes, monsters, foreground doors, furnitures...).

andycadley

I think the problem is that it looks too much like holes in the floor. You'd have to use it very sparingly, maybe just for dithering.

MacDeath

#70
Quote from: andycadley on 22:45, 24 March 25I think the problem is that it looks too much like holes in the floor. You'd have to use it very sparingly, maybe just for dithering.
I did a fast edition, tested with some grey zones but also some dithering (look, a stone is dithered) just as a test/proof of concept. Of course grey would then be used more properly to both differenciate a bit with the sprites, but not merge completely with the grey blank background.
Also "grey" is just Ink 0, can be changed into any other colour actually, and with properly modified HUD it would work and provide something akin to HeadOverHeels... but this is then a lot of extra work.

Worth a try?
Would look good but would make the shitty gameplay any better...

abalore

Quote from: MacDeath on 22:29, 24 March 25
Quote from: abalore on 21:29, 24 March 25Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparent
check again my previous post (I heavily edited it)
Yeah Grey is used for transparency and floor tiles use this for the "corners" but it can work as use-able colour too, just for those floor tiles and back-walls tiles I guess (because they are put over a grey background...) provided you put the grey on zones which won't then overlap with other floor/walls tiles.

Wouldn't be usable for the sprites (heroes, monsters, foreground doors, furnitures...).
Ok I get your point. Feel free to give a try, if you achieve a nice design I can use it.

MacDeath

#72
perhaps just something as simple as this could do the trick... should test it and see how it goes... would slightly highlight the stones with some slight lighter texture.
But Dark cyan and Grey are known to be very close to begin with... so the result would just be quite subtle. But may be enough to have the sprites being a bit differenciated from the background.
This would need some deep reflection to get more visible results but the idea is launched.

Also it may be interesting to check what happens when you temper with the letters font, just to see if they could be written with other inks/colours htan they are during the game... (they are 1 byte large and 8 rows height characters, data coded in mode2, as so often with speccy ports...)
What happens if you invert the colours/inks on those ?

according to Winape, paper is ink0 (grey) and Pen is ink1 (Dark blue) but some routine must exist to convert it a bit the way Locomotive Basic does to get the 1bpp characters set into mode1 (do they use firmware ?)

RedAngel

Dark cyan and grey are very close so one of them should be different but being able to use one more colour for walls and floor could help to improve the graphics.

MacDeath

#74
ok something like this then...

Also the sprites if they can be edited, would need some shadow added under them, this might help a lot actually..

Ok here are some evolution of a mockup...

Pink+Dark Cyan = Grey.
It works well on the stones actually.
And Pink+Pastel yellow gives a sort of pastel orange, it is a great "pseudo CGA yet better" palette actually.

Dark cyan + pastel yellow gos a bit on the greenish side but works well too.

Powered by SMFPacks Menu Editor Mod