Im back!! OK heres a few more details on the work so far:
PC: On the PC I have ended up using a routine ripped from a demo to check which display we are on and then during game setup scale and anti-alias the bitmaps from the 32bit data to 24bit, 16bit or 8bit depending on performancedata. As this is upfront this means that the game cache ( graphics to be used in this level in memory, graphics to be used in other levels rendered to fast access binary cache file on hard disk ). The main display is 320x200 but in that mode it uses 256x192. The next display available uses 640x400 ( and this is the resolution the graphics are drawn in ). Game algorithms are almost identical to the SAM routines, obviously the assembly is different to the routines I have in place on the SAM although the Z80 shows its common ancestry nicely. MIDI sound. SAM: Graphics: This uses "downgraded" graphics in 16 colours. Because we will spend the most time on making these look good and touching up the graphics so they dont look like routine scaled and degraded graphics this will be the version that has most of the time on it. The level data is loaded for 4 rooms at a time using intelligent caching ( buggy - must fix ) based on the map pattern ( for example if you dont have the green key it will not load up green rooms even if they are in the nearest quad ). Im struggling with my Z80 assembly at the moment as I am working from memory and example code, I also notice that I have got used to some of the Pentium extensions without realising it. Ive tried thinking about how I used to work out downgrading routines on the AMIGA for HAM, the rules were more complex than the line modifications that SAM VLSI ( or is it ASIC? ) can give us in mode 4. If I can get it to work I can hopefully take advantage of it to produce more colours on screen. Do people know if this degrades CPU performance or if it is handled by the other chip? Sound: Not sure on this one. Originally it had samples being spooled from memory but I think this is innefficient as it requires initial compression to avoid absorbing memory I want to optimise performance on the SAM but now I think I am going to look for MIDI routines, the SAM seems to have MIDI ports on the back so I will have a look at some of the excellent information out there about the hardware registers I need to prod to get it going. This will be the last thing I do on the SAM version as I want to get the playability right. The game engine on the SAM is the most efficient so far, because I have spent the most time squeezing out performance from it. It is smooth ( no idea of FPS yet - I have the feeling if I put up a counter I might slow it down or introduce bugs - still paranoid about my code ) and actually nicer to look at than the PC version so far as the sprite movement routines are more polished - you will see what I mean when I post up the first demos. Amiga: It works, Ive stopped fiddling with this version. 68k is NASTY to get right ( but also strangely elegant when you stop blaming it for your mistakes ). The integer performance of the 68k was actually 1.2x the SAM and the main reason the routines I was using back in 91/92 were slower on the Amiga was because of the size of the data I was shuffling about was different on the different machines. More notes: Im obviously a bit aware that I could tinker with this until destruction so Im going to make a concerted effort to finish it by the end of November in a polished fashion under the name "Castle Quest" - although I think that name may already be used somewhere. In the interim, to keep you all keen I will release demos that do not crash your machine so you can give me feedback and a level editor so people can contribute. If I release details about the graphics requirements then if people are interested they can contribute some graphics. The Isometric, someone pointed out that this would not be true 3d - correct. I would like to do a limited iteration voxel display. This is suited to integer performance which is where SAM still seems to shine. Are the FRED disks still running? If not do peeps want to set up a SAM portal? Im keen to kick back some life into this if I can, if machines cannot be sold then people can run emulators. Mozilla OK I stripped the libraries and took out the caching code to achieve the footprint on the PSION at the expense of introducing several bugs per line of code ( ahem ) and it only supported the HTML 1.0 constructs as everything else takes up memory to work out properly and I admit it I hacked it together. Anyway it is possible to strip down a browser. Networking support What about the SAM networking ports, I am hazarding a guess that most of you have several of them. IIRC it had a master/slave design. Any code examples people want to send me, I dont know that the bandwidth is but if I can support equivalent to 9600 baud then we are laughing. Because the SAM hardware and ROMs are predictable this is going to be the nicest one to complete. Strangely enough it isnt that hard to provide a game construction kit ( I know I know ) once you have put together a game engine properly ( which I never have done before now ). Ive been too long away from Assembler to get through this as quick as I had hoped, I confess to having used a Z80 cross compiler at the start to work out how my constructs would look in assembler. The PC version when I strip out the extras still compiles to 603k. I would do my nut trying to work this out so I am going to leave it bloated ( it still looks small compared to most of the stuff I have written for the 80x86 family ). I want some thoughts about how available some of these things are on the SAM: 1) hardware expansion port - can it support frame buffers, would it be worth my while trying to breadboard up a different graphics chip at some point, are there any examples of this already out there? 2) The soundcard - how much???? 3) Anyone towered a SAM? ;-) 4) Is there a SAM Carrier Command/Elite already or should I revive my wireframe rendering engine from the Amiga and port it to Z80 ( yes - when I finish what I have started ) and give it a shot? 5) Ive got 24 corrupt SAM disks on my hands ( damp ), any thoughts on how to rescue the data? 6) Who has the SAM rights? How much will they charge to have them bought from them? ( no I cant afford it but it would be nice ;-) ) 7) Finally, is there a decent GUI project for the SAM? Masking routines are simple so it would be a cinch to get the windowing working. 8) Where is there a catalogue of the fred disks, Ive seen catalogues up to 40 or so but there are nearly 80 odd!!! Z80 rules, maybe Im having a mid life crisis... Dave.
