Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jum

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



    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" :)

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

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




  5. Here is an updated version of WAV2LSF with source and Windows .exe.



    - Added "-c" option that outputs the "LSF" sound data as a C file (.h or .c) (for easier workflow)

    - Made it a bit more user-friendly w.r.t usage "help" and error messages



    - Handle 16-bit WAV files (as some audio editors can't output 8-bit WAV)

    - Output "packed" sample data as C code

    - Include C and ASM code for packed sample player


    If needed, I can put it on my github.


    Coming soon: Final version of my Bezerk clone, faster and now with VOICE! (hence the detour into "updating" WAV2LSF).


    Credits to Bastian for the original WAV2LSF.


    • Like 2

  6. I have been using similar macros for developing asm code using ca65.


    I really like the idea of structural assembly. It makes reading the code much easier.


    Do you have Lynx libs / macros you use with ca65? (I have a cc65 installation, which only has asminc/lynx.inc).


    Or even a "ca65 Lynx toolkit"? (wishful thinking :) )


    What is "structural assembly"?

  7. Excuse my ignorance, but I'm looking for information on how to set up / configure lynxass / BLL so I can build the hello_a.asm example. (I'm getting "Unsolved labels"error when I run lynxass).


    Is there a best/latest version of BLL I can download, and some documentation on how to build a simple example? (BLL download on http://www.monlynx.de/lynx/bll.htmlis broken).


    Alternatively is there any info/examples of how to build simple example using ca65?


    Thanks and apologies if I am missing something obvious.


    Edit: Nevermind - got it working by including the right macros/vardefs/includes.


    Did you use the version from github?




    No, I downloaded the version from this post (from sage) on AtariAge Lynx programming: http://atariage.com/forums/topic/259067-lyxass-updated/?do=findComment&comment=4091378

    (The github version seems to be 0.44/0.45)


    Correction: From chibiakuma's youtube videos ("keith s" on youtube), it looks like he's using VASM. However, his 6502 toolkit download also contains BLL and lynxass (in the Sources folder). (Interestingly, it also contains my Atari 5200 emulator "Jum52" :)


    And yes, no credits, but I'm not too bothered as his toolkit is "training material" and it looks like he put a lot of work into it.

  9. Thanks Karri. Some nice information there.


    What I really want is a replacement for TGI, that includes what TGI does not have (eg: audio, custom text, other draw routines which I have had to implement).


    ie: A more complete, integrated Lynx CC65 game lib.


    Probably the biggest problem would still be framgented and old documentation on this forum and spread out tools and tool-versions. A beginner would have to do a lot of research before having a viable workflow set up.




    A "single download" of a "Lynx Game Dev" .zip with CC65 and libs and proper documentation and samples would go a long way to making it easier to get into Lynx game dev.


    Edit: Preferably in github so people can contribute easier.

  10. Could you give some kind of examples what kind of functions a mid-level video/audio library would comprise of? I'm not so well versed in these things but I'm very curious of what kind of improvements would make sense.


    I've been happy lately because compared to 10 years ago there's a lot of things that are easier now thanks to Karri, Sage, LX.net, Ninjabba, TailChao and others sharing their stuff (Sage's chipper tracker for music, Karri's cart-segments, LX tutorials and Karri's template that incorporates everything needed for a game etc.), but I agree that it's probably not exactly super easy to start out with Lynx programming yet either! There's a lot of work connecting the dots and have all the tools and resources put together in a working work-flow.


    It could be interesting to get aboard more mid- to high- level coders that struggle with the low-level stuff, but that still would be able to create nice games with a bit easier 'game-framework-programming'. Sometimes I dream of being able to really just jump straight in creating a game for the Lynx like in some super simple but genius IDE like in pico-8.


    Would still be more interested in trying to make more games myself instead of the tools (backward approach i guess), but in my mind there seems to be a distinction between personalities who actually seem to be more interested in creating the actual tools and personalities who are more intrerested in creating the games, not exclusively, but at least a tendency. (I might be completely wrong). Or maybe it's just a matter of different approaches, the build all tools properly from the ground up before starting coding a game-guys and the 'hack' whatever we have in the simplest way possible to create a game-guys?


    These are my thoughts exactly. The goal we are all looking for is "How do we make it easier to make games/apps for the Lynx?".


    Some options are:

    - "Lynx BASIC" (a playform like Batari Basic or Calamari's 5200Basic)

    - "Lynx IDE" - an "all in one" IDE like the Pico8 style (sprite editor, sound/music editor, code editor, emulator, serial uploader) - this is just a dream.

    - Existing tools, but make them more integrated.


    As you say, a lot of new tools have been written in the last few yeas by Karri, Sage, LX.net, Ninjabba, TailChao and others. Their efforts are much appreciated. But the working dev environment and workflow are still pretty clunky, and not conducive to a creative process.


    I'm a "hack whatever we have in the simplest way possible to create a game" type of guy.


    So a Lynx new CC65 C library would have:

    - Video functions

    - Init video (set up buffers and collision buffer)

    - Sprite start (Suzy go)

    - Sprite draw busy?

    - Draw line, circle, arc, rectangle

    - Draw text

    - Check collisions

    - SwapBuffers (with or without vsync)


    - Audio functions

    - Init audio

    - Reset audio

    - Start sound on channel n with frequency f

    - Play MIDI note number

    - Predefined "instruments" (with shift bits, feedback bits and vol/pitch envelope)


    - Other

    - Load data from cartridge ROM

    - Write/read to EEPROM

    - Serial functions


    ...and other functions which are sure to exist in the BLL / ASM libraries but not in any C lib as far as I know.


    Purpose is to abstract out the low-level complexity (where possible). Also to have smallest overhead.


    Maybe also add things like a "simple sprite engine" which could manage an array of sprites in a more user-friendly way.

  11. I have recently been working on turning my old Lynx "Befok/Berzerk" demo ( http://jum.pdroms.de/lynx/lynxprog.html) into a complete game.


    It's taking longer than I thought, with detours into adapting an HTML sprite editor ("Tiny Sprite Editor") to use Lynx palette and output sprite data as C code, and a detour into relearning how Lynx audio works.


    Also had to convert/update the old CC65 code to use the new CC65 compiler (which is way better, thanks Karri). Working with the old code was probably a mistake - it would have taken me less time just to rewrite it from scratch.


    Also it's pretty grim for new people trying to get into Lynx programming. We need a proper mid-level Lynx C video/audio library. TGI is not the answer.


    Anyway, here is the alpha version of "Berzerkoids". It works on a real Lynx, but seems to crash every now and then. Does not crash on Handy. Recommend using Handy 0.98b.





    There are some audio issues and the bullets are not visible enough.


    Please give feedback.


    Edit: latest version of Berzerkoids is here: http://atariage.com/forums/topic/277916-berzerkoids-alpha/page-2?do=findComment&comment=4268115

    • Like 4

  12. Looks pretty cool but I haven't figure out how to modify the palette yet... or is it even possible? (having black for pen 0 is not optimal since pen 0 is also the transparent color).

    You can modify the palette in the HTML source code, or add your own palette. You can change pen 0 to pink if you prefer.


    Probably would be nice to be able to import a Lynx palette, either from C file data or from .gpl palette file. Let me know what format(s) would be most useful.


    Also have added to github as a fork of the original: https://github.com/james7780/tinyspriteeditor

  13. I have modified the online "Tiny Sprite Editor" ( http://tmtg.net/tinyspriteeditor/) made by Boris van Schooten, so that you can use it to create sprites for Atari Lynx.


    Double-click the .html file in the attached zip to run it.


    Currently you can export the sprite data as C code or ASM code (literal sprites only for now, can add RLE compressed sprites later).



    1. Run the .html file in Chrome (may work in other browsers too).

    2. Set the "Palette" drop down to "Atari Lynx" BEFORE you draw anything.

    3. Draw a pretty picture (background must be pen 0 (black))

    4. In the "Text Format" dropdown, select "Lynx C code (literal)"

    5. Click the "Export" button.

    6. The C code will appear in the textbox at the bottom of the page.


    Note: you cannot import C code at this stage. If you want to "Save" your sprites to work on later, then export as "Data URL".


    Let me know how it works for you. I am sure many improvements can be made.


    The main purpose is to make it easier to create Lynx sprites for your projects, without having to hassle with Gimp and PCX and sprpck/sp65 and bin2c...


    Have fun!


    Also have added to github as a fork of the original: https://github.com/j...inyspriteeditor


    • Like 1

  14. Comparison of the 2 screen clear methods, using Handy and using a real Lynx (note: real Lynx seems to be faster than Handy).


    Lynx clear screen method comparison

    Note: I think the frame rate is set to 75fps. If so I will do another comparision with 60 fps version.
    Edit: No difference when frame rate is changed to 60 using tgi_setframerate(60). Possibly tgi_setframerate() is broken?

  15. While I was writing "Always winter, never Christmas" I found out that at least Mednafen is so much faster than a real Lynx. So I would prefer to get these test results from a real Lynx if possible.


    The result sounds reasonable. The collision buffer is probably a great idea when dealing with random areas. But when you have a large, full-screen rectangle then drawing the whole area twice is faster than trying to draw into two buffers at once.


    I will test on real Lynx (using SD card adapter) and get some screenshots.

  16. So a quick test:


    1. Draw "clear" sprite to clear draw buffer and collision buffer, followed by a "playfield" sprite with collision enabled (1 call to Suzy) :



    2. Draw playfield sprite directly to collision buffer, then draw it to the draw buffer (2 calls to Suzy):



    The green area shows how many hcounts it took to draw. If you can believe Handy, then method 2 is way faster.


    (If you don't want to download/look at the images, then method 1 takes almost a whole frame, and method 2 takes about 60% of a frame = 60 hcounts).


    Results can be predicted from:

    Method 1:

    - Draw clear sprite = 75% of "normal" sprite draw time (NSDT), as it does not have to read pixels (write only)

    - Draw playfield sprite = 100% of NSDT

    - Total = 175% of NDST


    Method 2:

    - Draw background non-collideable sprite to collision buffer = 66% of NDST

    - Draw background non-collideable sprite to draw buffer = 66% of NDST

    - Total = 134% of NDST


    So you would expect method 2 to be about 30% faster, even before implementing it.


    (Also, why does it take almost a whole frame just to clear the draw buffer and collision buffer?)

  17. Thanks Karri and Sage.


    Karri - drawing sprite to the collision buffer directly is an interesting idea. Problem is that it does not save me any sprite draws, I still need to draw to the display buffer too. (Edit: actually I might try this, as it should be faster than a sprite writing to display buffer and collision buffer). Is there any source code out there that does this?


    Sage - true, however what I want is to write 0 to collision buffer for transparent pixels, and 1 to the collision buffer for opaque pixels. (ie: "clear" the collision buffer where no playfield is, and write 1 to collision buffer where there is playfield)


    My current collision code is correct and work properly, I was just wondering if there was a faster way to do it.

  • Create New...