Jump to content

andym00

Members
  • Content Count

    1,048
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by andym00


  1. That Level1 (the only one available) it's 504chars: XEO3 chars.zip

     

    IIRC, I think it used a flipped charset for the bottom half of the screen.. On that level at least..

     

    In my tests I did originally with looking at doing Xeo3 on the A8, I think I came up with 270 chars in total, which was easily splittable between 3 charsets that dynamically copied in characters through a simple runtime reference counting system which releases a char into the free pool when it leaves the left side, and allocates and copies a new one when we add it to the right, which adds nothing to the actual complexity, beyond a a few arrays to refcount, store forward and backward mappings without any need to preprocess the map.. Except for an absolute pathological worst case of 168bytes if every character is new, but then that time is split over many frames anyway..

     

    I honestly don't see what's stopping this happening on the A8.. The Plus/4 is slower (1MHZ with all DMA time and slow/fast cpu switches taken into account) than the A8 at this, and none of the Plus/4s colour features are being used, it's nothing by a 4 colour character screen.. It's having to move the entire screen (1K) every few frames which you can do via LMS magic and not have to move anything around in memory, it's running a SID music player as well (50FPS?) for the music (and we all know how fast those aren't), and a separate 2 channel SFX driver on TED sound. And even then the game is still only running at 25FPS at the end of the day.. The A8 should be able to absolutely ace this in 64K, and still have time to waste.. In fact, I would have thought the only major issue would be if it can actually be done at 50fps ?

     

    I don't even think it's a particularly good game personally, but as someone said earlier it's better than most of the other shooters on the A8 because stuff doesn't fly in a straight line, yet from a technical point of view I think it's not actually that good.. I'd suggest looking at the 64 version, and use the sprites from there with player underlays.. Hell, it's only a max of 10sprites, not even a big multiplexer..

     

    Bloody hell, I sound like you know who now :-D


  2. TED is described fairly simply here..

    http://mclauchlan.si...king12/gfx.html

     

    Character modes need $800 bytes of RAM for screen and color memory. The first $400 bytes act as color memory (the memory permanently located at $d800 on the C64), with the lower 4 bits containing color codes, exactly as found on the 64. Bits 4-6 denote the intensity level of the color, while the high bit select flashing/no-flashing attributes. The other $400 bytes contain the screen codes for the displayed characters. If hardware character inversion is selected, the lower 7 bits hold the screen code and the high bit selects inversion for the character. If character inversion is not selected, all 8 bits denote the screen code. Extended Color Mode (ECM) and Multi Color Mode (MCM) modes work exactly as described on the 64. While these two modes are in effect, inversion and blinking are disabled.

     

    edit: And the thing to realise with the 64 is the the colour memory is on it's own bus internally to VICII, so it can read one colour byte per cycle without using the main memory bus, which on a badline is saturated with graphics fetches and character code fetches..

    TEDs colour RAM is in main memory, hence needing 2 badlines to fetch all the data..


  3. Another huge marketing fails!

    NEXT CUBE

    122.jpg

     

    Marketing fail maybe, but not financially for the owners of Next.. Nextstep became Mac OS X after Jobs sold Next to Apple.. I don't think the $400 million Apple paid Next for it was technically a disaster from his point of view! What's also of interest is the other operating system that Apple was considering buying at that time to found the new OS was BeOS, which whilst awesome, was shot up the arse by the retarded and infamous 'focus shift'..


  4. By the way - note to those who want me to install VBXE boards - I'll make up SCART or RCA to DIN13 cables for an extra tenner. :)

     

     

     

    Cool! Can you add me to the list for a SCART cable then please That'll save even more potential destruction of innocent hardware by me :)


  5. VIC can do the drawing and the masking for you in sprites.. No need for software drawing and/or software masking.. Although you'd be limited to 4 sprites per line, or some other method to split the masking sprites down the screen without a 1:1 sprite to mask-sprite relationship..

    Unfortunately, very few games have ever used this approach.. Why ? I don't know.. There's no gotchas with it, just it's a weird use of the priority system and background:foreground priority relationship between sprites and the screen..

     

    Edit: And to show this, I've just attached a simple example of this effect.. Along with the raster time required to do it ;)

    sprite_mask_poc.zip


  6. Lol, 64 in crap game shocker! Seriously though, a lot of games were just banged out because people wanted to make money, and pushing the envelope from a technological point of view makes development more complicated and riskier..

    Only now when games are labours of love by people who don't have any financial interest can you explore every avenue..

    As an example, in the time since the Silkworm demo surfaced and now, I have in that time frame started, completed, debugged and shipped whole games.. Because that's how long I had and my bosses would have been none too chuffed if I'd taken a month longer just to add some colour that doesn't actually make the game any better :)

     

     

    I know all that... But the thing here it's the way C64 version it's done...

    It's not the crap it looks but the way, what they used instead of something common in all C64 games ;) ...

    Indeed, it's the only one I know in C64 builded this way.

     

    It's this that I would like see if someone discovers.

    If the coder could have it better or used other way it's another thing.

     

    No one guess?

     

    Looks like bitmap mode to me from the way it redraws, which if correct ,means they were free to do what they wanted with the colours within the usual limits.. Looking at the ST version, it has that same feel graphically, like maybe this was what the artist actually wanted to do ? The Amstrad version looks gross and green, and the Speccy version look, erm, spectrumy..

     

    I also think you might find this looks rather different on a real TV.. I don't want to try and second guess what the programmer/artist were thinking when they did this, but Gremlin weren't the masters of tat, so I'd imagine it was a no accident it looked like that though.. Could be wrong though and it could all be rubbish because of a colour-blind artist or something, but given it looks good to me actually, and does the job nicely..

     

    I am so looking forward to the day-glo A8 version ;)


  7. Lol, 64 in crap game shocker! Seriously though, a lot of games were just banged out because people wanted to make money, and pushing the envelope from a technological point of view makes development more complicated and riskier..

    Only now when games are labours of love by people who don't have any financial interest can you explore every avenue..

    As an example, in the time since the Silkworm demo surfaced and now, I have in that time frame started, completed, debugged and shipped whole games.. Because that's how long I had and my bosses would have been none too chuffed if I'd taken a month longer just to add some colour that doesn't actually make the game any better :)

     

    • Like 2

  8. Indeed, some small update (colouring, mostly on the Status Area) and I put some Enemys on screen for you to see how it could look:

    post-6517-0-14405700-1322199566_thumb.png

    ;-)

     

    Looks really really nice actually, and amazed that someone didn't clock earlier that Cybernoid was just ripe for this approach..

    Must admit, I'm not mad about the game itself ;)


  9. Emkay, why do you have to kill every thread with your own personal agenda ? Is it because you're jealous of those that do actually program for your beloved machine, because you can't ? Or because you have some genuine psychological disorder ? If it's the latter then I could at least make sense of your behavioural problems..

    Wish there was some way I could contribute a vote towards your eternal banning from these parts as you're nothing but destructive towards this community..

    • Like 5

  10. I've tried to order one, added to cart, checked out, signed up, entered address etc, then went to pay (via paypal), but the page kept failing to load.. And now I can't load a single page from there..

    Though I have received a mail confirming my order, though I still can't load any pages, and never actually reached any payment page..

    Is the fact I have an email receipt, confirmation enough that it's worked ?


  11. In that case I'll upload that here when I get to a computer.. First thing on my agenda is allow midline changes to occur.. I find that so annoying for debugging purposes :)

    Surprised by how many games don't work though.. ikari warriors is very weird, with and without cycle stealing from the CPU..

    All told its been an enlightening experience thus far, especially how good Maria is when it's not crippled with the indirect mode..


  12. Don't want to resurrect this too prematurely, but I've been playing with ProSystem over the last day mainly out of curiosity..

    So far I've got it building with last latest dxsdk (jun 2010) and building g under VS2010.. Still uses direct draw which is deprecated, but I've got it working with dinput8 now, so it'll build out of the box with the latest asks and ides.. I've also cleaned up all the warnings in the code, so now it compiles warning free at error level 4.. This also brought to light a fair few errors in th code..

    My main aim was to sort out the cycle accurate timing of it.. My first pass indicates that the CPU is left with too few cycles when taking into account the Maria timing.. The Maria cycle counts are wrong.. Sirius for example takes way more cycles for the Maria rendering that it has available.. My thinking is the hokey dma actually aborts the current dma operation rather than feeding 0's in.. Also the dma is aborted in the case of exceeding the 159'th lineram pixel.. Even with these allowances Sirius still takes more cycles than are available on some lines..

    I've also added a display that shows the Maria cycle useable per scanline, live on the display.. Very enlightening I can tell you..

    Also I've fixed the annoying sound system so it doesn't click loudly whenever it tries to pause the audio at startup, menus etc..

    Also it's speed up enormously now.. Uses around 1% of my i5 instead of maxing out one CPU previously..

    Either way, enabling the Maria cycle stealing leaves the CPU with way less cycles than expected..

    Particularly things like one on one and commando where there's clue splits and changes that aren't synced to the display, but instead are times loops. Which take longer than expected currently..

    That aside, I'm quite getting into the code, but it would take a massive overhaul to implement a debugger into it, given how it works..

    I'm wondering what work Groovybee and Curt might have done whilst working on the XM ? Am I repeating work you chaps have already done ? As I assume you've developed some emulation of it for development purposes ?

     

    Just wondering if there's any interest in these changes, and pursuing cycle accurate emulation ?


  13. PMSL.

     

    My thoughts - just redo the graphics for mode E and rework the softsprite render so the X coordinate is rounded down for 160 mode.

     

    Unless fully documented source exists, I kinda doubt anyone would want to redo this game.

     

    Best case scenario, the graphics and game could be redone in a couple of days. Of course, the crappy music and sfx, and slow gameplay will still be there.

     

    Given the artifact nature of the screen, going by the 7800 version, then the rendering would already be on 2 pixel boundaries otherwise things would look a bit mental when viewed properly on NTSC and moving in single pixel steps.. So surely that'd involve only changing the graphics ? Hell, you could even just set it into multicolour mode directly and see the results :)

    The source does exist as Heaven appears to have dug it out.. http://www.atariage....to-5200-please/

    Or is it not this 'version' ?

     

    I still think you could do it in char mode (if Emkay wanted to rewrite it from scratch), and get all the benefits of the speed of the handling of the tower as characters, since that's were all the magic lay :)

    The key is in the odd/even char lines in the tower, which I think can reduce the character set enough to fit into 2 sets.. Just an observation ;)


  14. That masking fail - looks like a rare case of gate being right next to a pillar.

     

    Might be some mess up in the masking or program problem. Or maybe a bit of both. Possibly the gate's presence is overriding the masking that the pillar specifies.

     

    Actually, yeah, looks like the animated pillar bit does override the mask for the pillar.. Interesting, and surprised if that was left like that in the original.. Anyway, not important in the grand scheme of things I guess..


  15. It is extremely interesting how no one has any problems with it being cartridge only. and not a single-load 64k. From teh C64-guys here I got teh impression that on C64 only these games are welcome...

     

    I think the acceptance is down to the fact the original game was on the IIe which meant it had 128K of RAM.. If you read the thread on CSDB you can see there's people asking that same question..

    http://noname.c64.org/csdb/forums/?roomid=7&topicid=87318&showallposts=1

×
×
  • Create New...