Fantasia!
CardboardGuru
Posts: 443
Fantasia is a new driver for displaying text. It uses the Dodgy Kong TV driver as is, and branches off the cooperative renderer framework, dropping tiles and sprites, and replacing them with text.
In the demo, it introduces itself.
Post Edited (CardboardGuru) : 6/5/2007 5:50:46 PM GMT
In the demo, it introduces itself.
Post Edited (CardboardGuru) : 6/5/2007 5:50:46 PM GMT
Comments
Excellent driver, nice job... if you don't mind I'll add a version of this to my modified TV.spin display, that way, people can have 320x512 PAL TV displays with this even 256x480 or whatever NTSC's limit is [noparse]:)[/noparse]
Baggers.
Thanks. I only started work on it yesterday, so it's at a very early stage so far. So I wouldn't think of branching from this for some time yet.
I'm looking forward to your PAL display. I wonder whether most American TVs can display PAL, just as ours can display NTSC. If so, we're all wasting our time doing NTSC displays and should move on to PAL.
So when you get a PAL demo going, you should run a forum poll to see how many it works for.
Seems to me, incorporating that would not cost much, but it just doesn't happen.
nice idea and great work. I have a little played with the code and I wonder why you use 6 Cogs for rendering, because I have not seen a difference when I was using 4 Cogs.
Thomas
Yes, obviously the number of cogs needed varies with the number of characters in the strings, particularly when they share a scanline. I just left it with the maximum number of cogs because the demo and the driver are works in progress. Max is 6 because there's one for the TV driver and one for the demo and Spin API.
Don't look too closely at the code just yet, as there's loads of obsolete stuff in there from when it was the DK renderer.
it's amazing. Very cool work.
Thomas
Are we all forgeting text games? I would love to see someone do a really fun text game like baby zork or something, with really beautiful text, nice background, maybe burnt aged paper. If anyone is interested in how to write text games with memory, vision, etc. I wrote a good intro to it years ago, and can probably find the chapter from the book it was in and post it here.
Let me know if anyone is up to the challenge of doing a text adventure game with a nice parser?
Andre'
However if you have the source to adventure, it would probably be pretty easy to port it to SPIN. Actually post the code in the forum, I am kind of curious to see it.
One word:- WOW!
Well done, I am continually amazed by the power of this little micro and by the programming skills of you guys...
Keep up the good work.
Best regards,
Coley
Baggers.
Re: Text adventures. It's of of the things I've thought about doing, but there's quite a few other ideas I fancy doing more. I didn't mention it as one of the things you could do with Fantasia in the demo because you'd want to use an interlaced TV driver for that. It'd look nicer, and give you twice as many lines of text on the screen. You'd probably want to use a narrower font than the standard ROM one, or perhaps have the driver resize the ROM font. 16x7 characters in Fantasia is no good.
In fact, you could go further with an adventure text TV driver, and reinterpret the ROM character set as a proportional font. All you'd need is a table of character widths. That would save a few horizontal pixels on some alphanumerics, and all punctuation and spaces. And also discard a few pixel lines at the top and bottom of the character set, as the interline spacing is quite generous. As well as saving space, it'd be nicer to read.
The original Crowther and Woods adventure was ported in it's entirety with a new endgame onto the BBC Micros by Level 9. It used the Mode 7 graphics mode, which gave you text using a 1KB character map. 3KB was used for the OS. So it fitted in 28K. It was early days for compression techniques, so they used a hombrew recursive compression technique that ran overnight looking for redundancy in the text strings.
But it seems to me that for the Hydra, this is a good use of the EEPROM. Shove the text resource file into upper EEPROM, and port the game logic to Spin.
Another possibility is to port one of the various text adventure interpreters that runs Infocom Z-code format, or Level 9 format files. You'd shove the entire game file in upper EEPROM, and run the interpreter in RAM. Frotz is the most widely ported and well used of these interpreters.
Everything that is in the public domain relating to adventure games is on the Interactive Fiction archive.
www.ifarchive.org/indexes/if-archiveXgamesXsource.html
Source code for the original Crowther and Woods adventure game, plus many derivatives is here. 350 point Crowther and Woods in Fortran is the original, but there's various ports there, including to C. But the C port I looked at was done with an automatic translation tool, so is rather obfuscated. If manually porting to Spin, I would think one would be better starting with the Fortran code than the C code.
There's a nice short history of how adventure came about here:
www.inform-fiction.org/manual/html/s46.html
It hints at why there are so many variants of the game.
Frotz source from the homepage here:
http://frotz.homeunix.org/frotz/
Anyone fancy taking the adventure game challenge on?
Well, isn't that the real "physical" resolution of the NTSC signal - one color per one color clock at 3.58MHz, 52.6us scanline -> 52.6 s * 10^-6 * 3.58 (1/s) * 10^6 = 188.306 clocks = 188.306 px. Of course, if you get a signal that resynchronizes with the PLL quickly (ie. is some multiple or a clever fractional multiple of 188) the colours wouldn't be much off.
EDIT: Changed the commas to dots.
Post Edited (Jasper_M) : 6/8/2007 9:07:31 AM GMT
That sounds about right. Though that will include overscan, so the actual display pixels would be somewhat lower. So I guess that explains the Parallax graphic driver/HEL decision to use 160 pixels horizontally.
Since asking the question, I decided to just try it out and see. I went down from 256 to 192 pixels horizontally. The colour accuracy was improved, but still a noticable change in hue of the pixels as they moved horizontally. Switching again to 160 pixels, the colors stay the same on the particles.
So practice bears out the theory.
In Finland we actually use commas as decimal separator : P ... After all that high school I got used to commas... Sorry about that : D...
And that pixels stuff is of course in the Hydra book too... My text mode driver (216 horizontal + overscan) has some problems with the colour too, white text changes between yellowish and blueish horizontally..
Andre'
No, the original was definitely Crowther and Woods in Fortran.
Three from line 141 to 144 ( since there's an empty line )
movs VCFG, #%0000_0111 ' VCFG'S = pinmask (pin31: 0000_0111 : pin24)
movd VCFG, #3 ' VCFG'D = pingroup (grp. 3 i.e. pins 24-31)
movi VCFG, #%0_10_111_000 ' baseband video on bottom nibble, 2-bit color, enable chroma on broadcast & baseband
Change to
movs VCFG, #%0111_0000 ' VCFG'S = pinmask (pin31: 0000_0111 : pin24)
movd VCFG, #1 ' VCFG'D = pingroup (grp. 3 i.e. pins 24-31)
movi VCFG, #%0_11_111_000 ' baseband video on bottom nibble, 2-bit color, enable chroma on broadcast & baseband
and line 289 from
tvport_mask long %0000_0111<<24
Change to
tvport_mask long %0000_0111<<12
Hope this helps,
Baggers.
I tried the code with my prop demo board but no sign of display.
I'm using 7.5" TFT LCD monitor.
Any other method that u can suggest?
Thanks
Sorry for the delay, was away for a much needed short holiday break [noparse]:)[/noparse]
AHHHH!,
I forgot one MAJOR thing lol
did you change
_clkmode = xtal1 + pll8x
_xinfreq = 10_000_000 + 0000
to
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 + 0000
in sw_fantasia_demo_002.spin