- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
Glad to see my teasing worked! I know the advantages of XML, it's just ugly.
Last time I checked the CPC was turing-complete, there is nothing it cannot process.
Yes my goal is to import .AKS songs from the CPC.
Ideally with a callback based parser, something resembling to:
Like that, the feeding mechanism is input-agnostic, it can be Amsdos File, Symbos File, Ramdisk or zip uncrunched on the fly. It prevents to have to load the whole thing in memory in the first place.
Where the description would look like:
The closing callback should be invoked with:
The callbacks would return Carry in case of success, NC in case of error, which would stop the parsing.
The .aks doesn't use attributes. Youpi!
In the first instance, we can also assume the order of the tags in the XML match the order of the description.
It should be pretty fun to program, yet I'd rather use some existing code, especially if it's Prodatron's stellar Z80!
Last time I checked the CPC was turing-complete, there is nothing it cannot process.
Yes my goal is to import .AKS songs from the CPC.
Ideally with a callback based parser, something resembling to:
Code Select
xml_parser
In: HL = description table
IX = input callback, a routine passed by the client, itself taking:
; BC = size (number of bytes to provide)
; DE = destination buffer (where to provide the bytes)
Like that, the feeding mechanism is input-agnostic, it can be Amsdos File, Symbos File, Ramdisk or zip uncrunched on the fly. It prevents to have to load the whole thing in memory in the first place.
Where the description would look like:
Code Select
root
; name of expected tag
db "song",0
; callbacks when entering / closing the tag
dw cb0_song, cb1_song
; list of subtags
dw instruments
dw subsongs
; ...
;end of list
dw 0
instruments
db "instruments",0
dw cb0_instruments,cb1_instruments
dw instrument
;...
dw 0
The closing callback should be invoked with:
Code Select
In: A = type of value
; 0 = no value
; 1 = 16 bits signed integer
; ... To be defined
;16 = string
HL = value or pointer to the value depending on the type.
The callbacks would return Carry in case of success, NC in case of error, which would stop the parsing.
The .aks doesn't use attributes. Youpi!
In the first instance, we can also assume the order of the tags in the XML match the order of the description.
It should be pretty fun to program, yet I'd rather use some existing code, especially if it's Prodatron's stellar Z80!
#2
Quote from: abalore on Yesterday at 17:31So agree on a score and then form an opinion?Quote from: Shaun M. Neary on Yesterday at 16:53Quote from: abalore on Yesterday at 15:59This is one of the cases I don't understand in CPCGR:Two different people reviewed those games though. So you're getting two very different opinions from two different mindsets. So I can understand why one got rated higher than the other.
A work of copy & paste elements from other 3 games has a lot higher score than the original. With all respect to Wizcat, the effort put on this Frankenstein game is nothing compared with what the programmers of Barbarian, Beyond the Ice Palace and IK+ did, to not talk about the creativity involved. I don't know if the final result is so much enjoyable for that score boost, but... really IK+ is so bad and the exact same thing is so good?
For what it's worth, I think IK+ deserves a lot higher than 5/10 but you'd need to ask @Nich what he was thinking at the time of writing and if his mind has changed on it now.
So, we got to the point. If you have inconsistent scoring, what's the reference at all? As a guide for someone to decide whether to try a game or not the usefulness dilute when you need to raise your eyes and check who is the author of the review. The site could have two scoring systems as in Rotten Tomatoes, Critics Score (Nich and his partners) and Public Score, based on users. A more complex system: sure, more useful: 100%
Did we turn into robots recently or something? That's not really how it works. There's nothing wrong with people having a difference of opinion.
Or did I misunderstand?
#3
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 ?)
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 ?)
#4
Quote from: MacDeath on Yesterday at 22:29Ok I get your point. Feel free to give a try, if you achieve a nice design I can use it.Quote from: abalore on Yesterday at 21:29Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparentcheck 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...).
#5
Quote from: andycadley on Yesterday at 22:45I 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...
#6
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.
#7
That monitor is such a beauty.
#8
Quote from: abalore on Yesterday at 21:29Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparentcheck 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...).
#9
Quote from: MacDeath on Yesterday at 21:10Because grey is used as key for transparency. In a isometric sprite, the four corners are always transparentQuote 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)?
#10
Technical support - Hardware related / Re: WIP: internal 512K expansi...
Last post by eto - Yesterday at 21:24Quote from: Egg Master on Yesterday at 19:55I'm not talking about the base 64K RAM, because it's not on your expansion.The 464 has 64K base ram. The iRAM adds 1024K (64 base + 2x 512) however from the second SRAM 64K are used for C3 emulation, thus reducing the available RAM of the second SRAM to 448K. This will give you a total of 1024K of RAM: 64K base + 512K SRAM1 + 448K SRAM2. And a total of 1024K is exactly the amount of RAM that SymbOS can address. So there is no benefit of having a solution without C3 as even with a full 1088K you would only get 1024K in SymbOS.
Obviously, it's in addition to the "512K + 64K" (640K) or "512K + 512K" (1088K).
Quote from: Egg Master on Yesterday at 19:55A 128K SRAM IC costs twice as much as 64K IC and is also twice as large.Which one do you have in mind? I can't find an available parallel 64K SRAM. I can find 32K SRAMs but then you need two of them.