Jump to content

jum

Members
  • Posts

    173
  • Joined

  • Last visited

Posts posted by jum

  1. Hi Karri, actually I just now found the cause of the crashes (after a LOT of SD card swapping :{ ?

     

    If I disable collisions, the game does not crash. I'm using the default TGI config with 2 draw buffers and collision buffer like so:

     

    // tgi locations of collision buffer (using -C lynx-coll.cfg in linker)
    #define COLLBUF 0xA058
    #define BUFFER1 0xC038
    #define BUFFER2 0xE018

     

    So possibly the stack is getting overwritten (underwritten?)? IDK, maybe something else?

     

  2. My game "Sky Raider" is almost finished, but as usual the last 10% takes more time than the first 90% :)

     

    I also need to compose a very short tune for the title / start. Something "stirring" similar to Apocalyse Now / Voyage of the Valkyries, or Star Wars, but shorter and simpler.

     

    Also still need to test/fix on real hardware, and do some optimisation/tweaking/polishing...

     

    Don't know if I will get it to 100% done before submitting. But I know if I submit it now, I will stop working on it... :)

     

    Here's the title screen sprite:

     

    sky_raider_title.png

    • Like 3
  3. The "Apple IIc Reference Manual Vol 2" has a section on the differences between a 6502 and a 65C02 (see "Appendix A"), that I came across today.

     

    A few instructions take 1 less cycle, and one instruction (JMP abs) takes 1 more cycle.

     

    The BIT instr affects status register bits differently, and JMP indirect can differ.

     

     

     

  4. On 11/4/2018 at 2:54 AM, Nop90 said:

    Managed to fix palette output in sprpck. The code assumes the use of windows bmp v1, that has a fixed header size, but since the time sprpck was originally coded micosoft evolved the bmp format adding other bmp versions with variable header size and optional data after the header.

     

    To fix the code I read the some data from the header itself to locate the starting point of the palette. Didn't tested it with every possible bmp format, but at least with the files generated from GIMP it now works fine.

     

    If someone is interested in using sprpck instead of SP65 i can upload the fixed code on my github.

    Thank you Nop90. I have also had this "bad palette" problem with sprpck and BMP files (generated using GIMP).

     

    Please add a link to your github with fixed sprpck. Thanks.

     

  5. On 6/20/2019 at 12:34 PM, Nop90 said:

    The drawback of your struct is that it expects to chain always sprites of the same type (in this case a full sprite with scale info, palette and collision data) while having a field with a pointer to a generic char array allow you to chain different sprites types, that in the end can make you save memory.

     

    Hope to not seem rude, I don't want criticize  you code. Often I wrote ugly code if it works at first try. I'm only giving my 2 cents to encourage the discussion.

     

    No offense taken :)  It's just an alternative way to set up simple SCB chain. You could also save 8 bytes per sprite by leaving the palette mapping out of your SCB struct, and manually setting the palette mapping before drawing the sprite chain. Depends on what you are doing, how many sprites you have, etc.

     

  6. This is how I have my SCB struct defined:

     

    // Lynx Sprite Control Block structure
    typedef struct SCB {
        uchar sprctl0;
        uchar sprctl1;
        uchar sprcoll;            // spr collision number
        struct SCB *next;
        uchar *data;
        signed int hpos;
        signed int vpos; 
        uint hscale;
        uint vscale;
        uchar palmap[8];
        uint collResult;        // collision result data (offset = 23)
    } TSCB;

     

    Note "struct SCB *next;". This allows us to reference the next SCB without casting, like so:


     

    struct SCB clearSCB =    {    0xc0,            // 4bpp / bg_no_collision
                                0x10,            // compressed, hsize/vsize
                                0x00,            // 0 to clear coll buffer 
                                &playerSCB, sprclr,
                                0x100, 0x100, 0xa000, 0x6600,
                                { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef },
                                0 };
    

     

     

     

     

  7. Yes, I've read the full tutorial on how to set up and compile the dev environment (thanks for writing them).

    To be honest, as it looked like quite complicated with a lot of stuff to install, I was hoping that there was some precompiled windows builds floating around, even if they are not up to date, so I could go through a simplified / easier process :).

     

    Do you confirm me that they're isn't any compiled release available?

     

    I am using a precompiled Windows version of CC65 (on Windows 7).

     

    Just looked up where I got it from: https://sourceforge.net/projects/cc65/

     

    It seems to be 4 years old now.

     

    I followed the link from the CC65 main page: https://cc65.github.io/

     

    Not sure if there is something better now, but this version is much better than the "old" cc65.

     

    Edit: Looking at the https://github.com/cc65/cc65 src files, it seems there is some recent activity. May be possible to build cc65 using Visual Studio?

     

    - Jum

     

    PS: I anyone has any ideas on how to do a fast vertically scrolling playfield on the Lynx, please let me know. At the moment I am experimenting with using 2 80 x 102 sprites, stretched 4x horizontally.

  8. I'm a gonna register (as soon as I decide what I want to do).

     

    Haven't entered a console programming contest since 2005! (Chopper X in PDRoms 3.33 competition).

     

    May pull out an old unfinished demo/proto and finish it off, or maybe do a very simple new game, probably involving dachshunds...

     

    Alternatively, I can be a judge if you need one.

    • Like 1
  9. Bug report on real hardware:

     

    - The ghosting of the walls is pretty bad.

     

    - Sometimes when there is a robot above me I try

    to shoot up, but nothing happens. Even if I move

    up a little, it still does not work.

     

     

    Thanks Chris. Not sure what causes the "ghosting" of the vertical walls, I just assumed it was my Lynx' old and crappy screen :)

    I think the "jamming" of the gun may be caused by the bullets going off-screen without hitting anything, and since the player has 2 bullets that are recycled, he can't fire until they time out. I will check and fix this.

    (You can maybe try to avoid this problem by not firing out a doorway?).

     

    Edit: Seems ghosting may be caused by bad capacitor(s) in the Lynx.

  10. Berzerkoids "alpha 3" attached. (Only tested in Handy)

     

    Changes as per bhall's suggestions:

    - Use inner or outer fire button to fire.

    - Prompt to press any key to start on the title screen

    - "Get ready" message before every level

    - Level scrolls off the screen when you finish it.

    - Slightly pulsating walls (it's quite subtle to avoid being too distracting).

     

    Also a fix to the bullet colour (now always white).

     

    Edit: attached file removed - see updated berzerkoids_alpha3a post below.

    • Like 2
  11.  

     

    Here are some ideas…

    • Allow both A & B buttons to act as fire button (unless you plan to use the B button for something else later on?)
    • Something on title/splash screen to tell you to press a button or move to start the game
    • Scrolling the play field as you move from room to room would be nice
    • Is it possible to play the sampled sounds async? (Or are you doing it sync on purpose?)
    • This wasn’t in the original, but the comment about not knowing the walls would kill you… Is it possible to color cycle animate the walls? (Does Lynx support indirection like that? like 4/800 did?)

     

    Thanks for the suggestions, they are all do-able.

    The voice samples will stay as they are (freezes while playing them back), as in the original. Also it makes it more dramatic :)

     

    I will see what I can do within the next week or two...

     

    PS: It's "Berzerkoids" :)

  12. Sorry, may bad for not testing it on real hardware.

     

    Seems that the Lynx does not like my "raw text printing" routine, so I have removed it an updated the download in post #16 above. Please re-download and try again.

     

    Picked up some other issues on real hardware (screen refresh/vsync, sound glitches, bullet visibility).

     

    Thanks for trying it :)

  13. Here is the latest (and maybe final) version of Berzerkoids for Lynx.

     

    I have only tested on Handy so far, still have to test with my RetroHQ Lynx SD card.

     

    Main changes are some minor speed improvements, and some voice samples.

     

    Edit: Replaced the attached version with one that works on real hardware.

     

     

    bezerkoids_alpha2.zip

×
×
  • Create New...