Jump to content

Andrew Davie

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Andrew Davie

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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....





    • Like 6

  6. 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___ 
        __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

  7. 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

  8. 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!

  9. 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

  10. 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

  11. 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


    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

  13. 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.


  14. 3 minutes ago, Colonel Llama said:

    Wow, this is looking great!

    Did you use that same techniques as in the Boulder Dash port?

    Well the triple-line "ChronoColour(TM)" system for multi-coloured graphics is the same.

    But it's a complete code rewrite and shares zero bytes of code/data with BD.  BD was 6507 code, 3E bankswitching.

    This is C-code and CDFJ bankswitching. Completely different technologies.


  15. Here's a new element -- "scalators".  They're a kind of automated spiral elevator for moving up/down shafts.

    There's a slow downscalator left, and a fast upscalator, right.

    The idea is you can move into the shaft and the scalator carries you up/down, and exit when you want/can.

    I'll probably add short demo videos of each element as it comes online...



    • Like 5


    Wen Hop?

    The Search for Planet X


    You're the very, very famous and dashingly handsome spaceman/explorer/all-round-good-guy, Mellon Husk. To save humanity from the "Great Filter" that you fear is coming soon, you are on a mission to find "Planet X" so that you can establish a new human colony and safeguard the future of humankind.



    Using your trusty rocket-ship, inspirationally named "ship", you are on a mission to visit the moons, planets, asteroids of the solar system to find that elusive new home. Your goal at each stop, to mine enough dogecoin (yes, in the form of actual physical coins) enable you to buy enough rocket fuel to continue your quest. Getting the dogecoins would be a matter of solving puzzles and avoiding aliens on the planet. It's going to be very much an action/puzzler.


    Each planet/location has its own gravity. Terrain will have different characteristics - for example, friction on an ice planet.  Underwater swimming...  I hope to spend some considerable effort on variations in controls.  The terrain is fully navigable on a per-pixel basis rather than character graphics. That is, Husk's movement is freeform over the char background.  You cannot dig underground, but you can follow existing passages, and of course you can use tools. You will be able to pick up and drop some "objects" such as explosives, and rocks. Use rocks to allow you to reach stuff, or to drop on enemies, or block off exits. Use explosives to open up new passages. Underground you can crawl along diagonal passages. You cannot move "up" - you have to jump or climb. There may even be some alien superstructure/buildings - maybe you can even go inside for a sub-level on the planet. Whatever I can implement. Maybe a rocket pack....


    At the moment the player sprite is just there to allow me to scroll around. It is not coupled to the background. That will come soon. At the start of each planet, I plan to have a big animating ship (character graphics) landing you on the playfield.  Out comes spaceman Husk and then you're in control. You try and collect the dogecoin by moving through the underground passages and using tools/explosives where necessary to get access. Once you get enough Dogecoin, you go back to the ship and it lifts off (huge animation) for the next adventure.
    The video shows what I have so far. Essentially, it's a graphics engine that has the following capabilities...


    * super-smooth playfield scrolling
    * Animating background character graphics
    * parallax scrolling.... pretty cool effect

    * lava
    * water
    * earthquakes / screen shake


    Objects/creatures/behaviour... this will be expanded...


    * water drips
    * alien eggs
    * various foe - chasers, huggers, etc
    * dogecoin



    * rocks - can be lifted/carried
    * explosives - place underground to blast away soil/rocks

    So as a first pass I've worked on the dirt and made it so that it intelligently "rounds" the edges where appropriate. It gives the whole thing an organic (non-character-graphics) feel.  I feel that I work better when I get feedback, and I do like to share new developments ASAP.  So I hope/plan to occasionally update this thread with videos and very soon some playable binaries.


    What you see in the video currently runs just fine on actual hardware.  I've tried to show a few of the features - lava (which destroys just about everything) and causes earthquakes. Rocks (eventually) explode when in lava.  Water, which dissolves soil/dirt, and will perhaps enable access to areas you might not otherwise reach. In other words, you float/swim until you're high enough. Both water/lava can slowly rise in level.   I'll be putting in what gameplay elements I can.


    Well, if you want to contribute suggestions for gameplay, feel free to do so.  And if you "follow" this thread, that will let me gauge interest in the project.  It's a CDFJ (32K) project, written mostly in C.  I'm really pushing the hardware with this engine;  it's incredible what you can make it do if you design to the capability. I'm already very short of space, so it's going to be a matter of optimising from here on in.


    Onward and upward!!




                                   wow                          so various           
                                   such example                            wow      
             so much blast       such first           so much objects                       
        such matter                   very necessary                    so physical      
                                                  such spaceman                              




    • Like 26

  17. Here is a minor update. The holes for the MicroSD module were a bit small, and have been enlarged.

    4 hours ago, WicoKid said:

    After reading the thread on the PlusCartSD and watching the youtube videos, it is my next DIY project. However later in the thread there are downloads for firmware but after updates to PCB are mentioned,  I cannot find the updated Gerber files and cannot locate them on GitHub or even from video links. Sorry if I'm breaking some ettiquitte by asking....its hard to tell if the thread is a developer exchange or an open to all situation as far as the Gerber files.


    I have just posted the latest board/schematics, and a GERBER export using PCBWay's CAM file for 2 layer boards into the tread @Al_Nafuur linked above. There was only a minor hole-size change, but makes all the difference when assembling.

    • Like 2

  18. Here is a minor update to the EAGLE board/schematics, and GERBER as well.

    The holes for the MicroSD board were slightly too small, and made mounting difficult. This fixes that.

    Edit: updated to include the MicroSD library defininition.




  19. These days I think "cheating" is a highly loaded word that detracts from any discussion on the subject. I think it places an implicit and unfair judgement on the ethics of programmers of ARM-based games, which I think should be unwelcome in our hobby. So, even in quotes, I would like to see this word removed from the discussion.

    • Like 6
    • Thanks 1
  • Create New...