Jump to content

Andrew Davie

Members
  • Content Count

    4,747
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Andrew Davie


  1. So, rocks.  The problem is now that because you can't dig, and you need navigable passages... how are these passages *defined*?  If we allow the rocks to fall, then as soon as a navigable passageway is opened ... the rocks will fall down and close it up.  So, I've been thinking about these things; how to maintain passageways, and how to open up passageways in the first place.  I think I've solved both of these, and found a use for the "alien eggs" in the process. We're going to switch the "eggs" to "soil eating mega-microbes".  You can see them in operation at the start of this video. Basically they eat dirt nearby, but die off pretty quickly. Husk may very well use these microbes as a tool to clear out passageways.  In any case, you'll notice from earlier versions that the rocks clump together in giant conglomerations of rocks. But now, there's quite a bit of behaviour differences; firstly the individual rocks will fall if unsupported. But the conglomerate rocks will be sturdy. How sturdy depends on what's happening; earthquakes and individual rocks can become loose (and you see them shaking before they fall).  Also, conglomerations can just spontaneously start to disintegrate - and I can vary this based on time, or difficulty, etc.  So although the passageways are maintained in esentially the same form, they do slowly disintegrate - but in a way that I consider "fair" and "avoidable" - in that you're not going to have a ton of rocks fall on you unfairly.  In the video you see the mega-microbes at first, clearing out some passageways. Then you see the earthquakes disrupting/destroying the dirt, and also the individual rocks falling as appropriate. Finally, you see the conglomerates slowly disintegrate over time.  I move around to show that there are still clear and distinct passages for most of the entire time.  Pretty happy with this.

     

     

    Edit: it's pretty clear Husk is going to need a grappling hook, so let's chalk that in.

     

    • Like 1

  2. I really enjoyed watching the @ZeroPage Homebrew twitch stream today with James and Tanya. They reviewed "Wen Hop?" and it was a hoot. I particularly enjoyed the smirky reactions to the implicit innuendo...  the relevant part starts at the 55 minute mark..

    https://www.twitch.tv/videos/1100209904

     

    As I wrote to James...  

     

    You'll notice I've animated the ship's "balldoges".  Known in the industry as "the ship's balls", for short. These hold the dogecoin you collect, and feed them to the engine by shaking when in flight. SO when you're flying high, your (doge)balls are in action. These are actually implemented as separate sprites (the ship is 4 sprites - the base ship itself, the two balldoges, and the flag).  The balldoges will change in size depending on how much dogecoin they're holding. So you will see your (doge)balls shrinking if you spend too much time goofing around. If your balls shrink to nothing, you're dead as a dodo.  I'm thinking that you don't actually get true credit for the dogecoin you collect, until you actually return to the ship and fill the balldoges with your loot. So it will be a balance between "banking" coin and available time to complete a level. Of course like with everything, too much of a good thing and you might bust your (doge)balls.  Haha.

     

     

    Great job James/Tanya - you did justice to the engine/demo... TY

     

     

    • Like 2
    • Thanks 1

  3. 10 hours ago, cfarl said:

    Hi, Andrew, great job here!

     

    I was looking at your Gerber file, but I didn't find the drill file inside it.

     

    Is it missing?

     

    Ps. I never ordered a pcb before, but I really want to make this for my Atari 2600.

    Yes, I think it's missing. I recall getting a similar question from board manufacturer.

    I'll look into it, but in any case anyone knowledgeable should be able to regenerate the correct files from the brd/sch provided.

     


  4. But... does it run on actual hardware?  Well, yes it does. Mostly!  This is my first test... I can get two of the ships going at the same time with not too many issues. Along with all the scrolling and other background animation/processing. It starts to disintegrate with 3 or more ships, so you see it reset/crash a fair bit. This is fine; the resets are probably the Harmony Cart deciding to gracefully exit when overtime. Still some optimisations in the pipeline, so all good. And the colours on an actual TV - excellent!

     

     

     

     

     

    • Like 8

  5. Though not really practical (with scrolling background) on real hardware, the stand-alone sprite system should be able to handle this many bitmap sprites (and more...). Maybe with slowdown. Just putting this video up for posterity.

     

     

     

     

     

    • Like 6

  6. 1 hour ago, Bomberman94 said:

    This is so colorful in the video! I think how the colors are with my PAL Atari 2600 as I think you brought us a NTSC version of it?!

    A quick test in Stella with PAL hardwired shows that the default (automatic) conversion of colours will look OK...  I can tweak this later...

     

     

     

     

    • Like 1

  7. 1 hour ago, Bomberman94 said:

    This is so colorful in the video! I think how the colors are with my PAL Atari 2600 as I think you brought us a NTSC version of it?!

    Good point. No idea at the moment. Well, sort of no idea. The colours are formed from a tricolour selection - say, red/green/blue and all 8 combinations of those together giving you the colours you see.  So for PAL I find similar colours to that red/green/blue and we get similar colours on PAL.  It will be quite similar, in other words.  There is automatic PAL/NTSC detection in there; that's possibly just not working at the moment. I have been testing on a NTSC machine. I'll get to the PAL stuff after I'm done with work on the engine.

    • Like 1

  8. The spaceship is now "tied" to the background scroll, rather than being drawn on the front of the screen, so to speak.

    the lock isn't perfect, but I'll get there. This is looking pretty busy...  now to make it a game...

    See my other thread for a binary with Husk's antagonist's first appearance... the evil Space Pirate Billionaire Dozeoff.  Well, his ship, anyway....

     

     

     

     

     

     

    • Like 6

  9. This is the dumping thread for demo binaries of my new ChronoColour(TM) Sprite System.

    This first demo just has spaceships;  I plan to have it running some fighter sprites to see how it looks.

    This will probably bork on hardware; it's not too far away, though, from working if it does.

     

    No interaction here... purely a demo.

    My goal is to refine the system and see how much speed I can get, and thus how many/big sprites can be drawn.

    Also, to see if a fighting game using this is feasible. I suspect so....

     

     

     

    BIGASS20210726.bin

    • Like 6

  10. One of those ideas on my bucket list for some time has been a "big sprite system" using PF graphics. With the spaceship, I've now managed to get this functioning. The ship-draw is actually a generic draw of any sized (up to 32 PF wide, unlimited depth) sprite, with masking.  In this demo - which is not truly practical due to timing - you see 5 ships moving around the same time and the background still doing all its stuff.  But the point of showing this is that I can imagine/see a 4-player fighting game with sprites this size.  Each PF sprite has a configurable centerpoint, so when you draw at a particular coordinate, the frame(s) shift around to keep the center point in the same spot on the screen.  This draw is happening at 60Hz. I may work on a stand-alone engine to allow this big sprite system to be used by others;  it's extremely simple to define shapes, and even easier to draw...

     

    Here's the definition of the ship (and mask)... side by side for ease of editing...

    const unsigned char rocketShip[] = {
    
        1,                  // width in BYTES (=8 pix/byte) (MAX =4)
        105,                 // height in SCANLINES (pref multiples of 3 -- TRIPIXs)
        3,105,               // center point (PIXELS) from 0,0 top left
    
        ________ ________    // colour 0
        ________ ________    // colour 1
        ________ ________    // colour 2 etc...
        ___X____ ___X____ 
        ________ ________ 
        ________ ________ 
        ________ ________ 
        ___X____ ___X____ 
        ________ ___X____ 
        ___X____ ___X____ 
        ___X____ ___X____ 
        ________ ___X____ 
        __XXX___ __XXX___ 
        __XXX___ __XXX___ 
        ___XX___ __XXX___ 
        __XXX___ __XXX___ 
        __XXX___ __XXX___ 
        ___XX___ __XXX___ 
        ___X____ __XXX___
        __X_X___ __XXX___ 
        ___XX___ __XXX___ 
        ___X____ __XXX___  // 00
        __XXX___ __XXX___  // 01
        ___X____ __XXX___  // 02
        __XXX___ __XXX___  // 03
        _XXXXX__ _XXXXX__  // 04
        __XXX___ __XXX___  // 05
        _XXXXX__ _XXXXX__  // 06
        _XXXXX__ _XXXXX__  // 07
        __XXXX__ _XXXXX__  // 08
        _XXXXX__ _XXXXX__  // 09
        _XXXXX__ _XXXXX__  // 10
        __XX_X__ _XXXXX__  // 11
        _XXX_X__ _XXXXX__  // 12
        _XX_____ _XXXXX__  // 13
        __X_____ _XXXXX__  // 14
        _XXX_X__ _XXXXX__  // 15
        _XXX_X__ _XXXXX__  // 16
        __XXXX__ _XXXXX__  // 17
        XXXX_XX_ XXXXXXX_  // 18
        XXXX_XX_ XXXXXXX_  // 19
        _XXXXXX_ XXXXXXX_  // 20
        XXX___X_ XXXXXXX_  // 00
        XXX___X_ XXXXXXX_  // 01
        _XXXXXX_ XXXXXXX_  // 02
        XXX___X_ XXXXXXX_  // 03
        XXX___X_ XXXXXXX_  // 04
        _XXXXXX_ XXXXXXX_  // 05
        XXXX_XX_ XXXXXXX_  // 06
        XXXX_XX_ XXXXXXX_  // 07
        _XXXXXX_ XXXXXXX_  // 08
        XXXXXXX_ XXXXXXX_  // 09
        XXXXXXX_ XXXXXXX_  // 10
        _XXXXXX_ XXXXXXX_  // 11
        XXXX__X_ XXXXXXX_  // 12
        XXXXXXX_ XXXXXXX_  // 13
        _XXXXXX_ XXXXXXX_  // 14
        XXXX__X_ XXXXXXX_  // 15
        XXXXXXX_ XXXXXXX_  // 16
        _XXXXXX_ XXXXXXX_  // 17
        XXXX__X_ XXXXXXX_  // 18
        XXXXXXX_ XXXXXXX_  // 19
        _XXXXXX_ XXXXXXX_  // 20
        XXXXXXX_ XXXXXXX_  // 00
        XXXXXXX_ XXXXXXX_  // 01
        _XXXXXX_ XXXXXXX_  // 02
        XXXXXXX_ XXXXXXX_  // 03
        XXXXXXX_ XXXXXXX_  // 04
        _XXXXXX_ XXXXXXX_  // 05
        XXXXXXX_ XXXXXXX_  // 06
        XXXXXXX_ XXXXXXX_  // 07
        _XXXXXX_ XXXXXXX_  // 08
        XXXXXXX_ XXXXXXX_  // 09
        XXXXXXX_ XXXXXXX_  // 10
        _XXXXXX_ XXXXXXX_  // 11
        XXXXXXX_ XXXXXXX_  // 12
        XXXXXXX_ XXXXXXX_  // 13
        ________ XXXXXXX_  // 14
        _XXXXX__ _XXXXX__  // 15
        __XXXX__ _XXXXX__  // 16
        __XXXX__ _XXXXX__  // 17
        __XXX___ __XXX___  // 18
        _____X__ _XXXXX__  // 19
        __XXXX__ _XXXXX__  // 20
        __XXX___ __XXX___ 
        __XXX___ __XXX___ 
        __XXX___ __XXX___ 
        __XXX___ __XXX___ 
        _XX_XX__ _XXXXX__ 
        _XXXXX__ _XXXXX__ 
        __XXX___ __XXX___ 
        XXXXXXX_ XXXXXXX_ 
        XXXXXXX_ XXXXXXX_ 
        __XXX___ __XXX___ 
        __XXX___ XXXXXXX_ 
        X_XXX_X_ XXXXXXX_ 
        __XXX___ _XXXX___ 
        ________ XXXXXXX_ 
        X_XXX_X_ X_XXX_X_ 
        ___X____ X_XXX_X_ 
        ________ X__X__X_ 
        X__X__X_ X_XXX_X_ 
        ________ X_XXX_X_ 
        ________ X_____X_ 
        X_____X_ X_____X_ 
    };

    Here's how to draw the ship... and flickery flame....  you don't need to erase... just draw things where you want...

     

    drawBitmap(&rocketShip[0], x, y, false);
    if (!(getRandom32() & 3))
    	drawBitmap(&rocketShipFlame[0], x, y, false);

    In the above example, a ship and the rocket flame share the same x,y coordinate (centerpoint). The flame will appear below the engine, because the center point of the ship is at bottom center of engine, and the centerpoint of the flame is top center. Anyway, I digress... it's a lovely thing.  Using the ChronoColour(TM) system, as this does, each sprite can have 9 ICC colours (that is, 8 colours of ICC AND a transparent "colour" due to the mask capability).

     

     

    • Like 8

  11. I'm thinking of attaching that drill rig thing to the side of the ship. So, you land in the ship and drill down to bedrock. The bedrock explodes to bitcoin, then you get out and climb your way down and fetch the coin. I just like the idea of this massive ship being used as a mining tool.  To move around, you'd get in the ship again, take off/fly to a different area, drill again...

    • Like 1

  12. On 7/17/2021 at 6:58 PM, Gateway said:

    I wish you a speedy recovery/adjustment period. How is your eyesight now? Can you still write code, etc.?

    I empathize with your situation as I lost 75% of my hearing in my left ear and a bit in my right ear as well, as a child. It can be a struggle on some days. 😕

     

    I am also challenged when it comes to hearing. But I refuse to consider this a disability; it is what it is. My viewpoint is that there are others in far worse shape, and I'm lucky to have the capabilities I do. Soldier on!


  13. 8 minutes ago, Gemintronic said:

    In Boulderdash my impression was you needed to figure out a system to manage events (like rocks falling) and do as much as you can until CPU time ran out then schedule them for the next frame.

     

    Do you do something similar here and does your overall threading strategy/management change going from assembly to C?

     

    Yes, the original (3E) BD operated in that fashion - a timeslice system that prioritised certain events, and where necessary slowed down the game to get everything done (although that was barely noticeable and rarely happened). There's a reason it took most of a decade to develop... it was probably the most complex piece of coding I've worked on. This engine is totally different, as there is enough processor grunt to allow me to brute-force a lot of the processing and all of the draw.  And of course I can program it in C which is 1000x easier and less error prone. BD could draw a maximum of about 8 onscreen "characters" in any single frame.  It had extensive, and very complex code, to determine what changed on the screen and thus absolutely had to be drawn. It then did that and no more. And if you had an erase/draw "split" over two frames, you could get a momentary flicker - but almost never noticeable... I just know it's there.  This engine does away with all that complexity, and draws the entire screen (all 10x8 characters) every single frame.  I do have some time management code to ensure that things don't run overtime, but the screen is always drawn in full every frame. BD only updated the changed characters. With the new system I can animate everything onscreen at the same time, with no time penalty; it costs the same to have a static screen as it does to have everything going crazy as in the video. There is no priority/timeslice/scheduling system like in BD. The code is way, way, way more simple in this new engine. There's a reason that BD took many years to develop.

     

    So saying, this is a different technology and a new challenge, and it has its own limitations and gotchas. I'm enjoying exploring this part of the envelope, so to speak. I've taken the opportunity to write totally new animation/draw/game systems to take advantage of the speed but also to make it much more versatile. There's zero reuse of code/techniques between the two. I'll be happy when we can move on from BD comparisons and appreciate this engine/game as a standalone new thing.

     

     

     

     

    • Like 4
    • Thanks 2

  14. Here's a bit of full-on action with lava, and earthquakes turned up to high. The earthquake shakes the screen, of course, but it also weakens the soil/dirt, so occasionally some will crumble away and rocks will fall/reconfigure. You can see the basic reconfiguration of the lumps of rock in real time. The rocks aren't exactly falling correctly yet, as I'm optimising to save space and changing the logic as a result. But it's good enough. This all has full-on sound... explosions, too. 

     

     

    • Like 3

  15. Next up; a rock drill. My original intention was to have this as a tool that Commander Husk could use, but I think it might be better as an obstacle on screens. The drill causes rocks to split/explode into dogecoin, because how else are you going to mine doge underground?  In the video I do a number of resets to watch it in action.  Also note the refined "rock clumping", which is working very well now...

     

     

    • Like 2

  16.  

    I've merged the rocks into giant lumps - this has had the nice effect of emphasising navigable passages.  The rocks can/should still break-off the lumps and fall... so the same functionality. Here you may also see the ground slowly disappear as the earthquakes (from lava and exploding rocks) are happening. I haven't got all the rocks operational in this video, but the general idea seems sound.

     

    EDIT/NOTE The video looks much nicer/brighter if you switch it to 720p/60!

     

     

     

    • Like 6

  17. 1 minute ago, Colonel Llama said:

    This explains why it looked a bit similar!

    Can’t wait to try it!

     

    Also, i love Husk’s animation XD

    Also used the same ChronoColour(TM) concept in my Chess, Sokoboo, Life in Space and several demos.

    Husk has many animations already done;  I have to "tie" him to the background and then he can start using them.

     

×
×
  • Create New...