Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by rje

  1. On 9/20/2022 at 10:30 AM, kelli217 said:



    I'm also getting philosophical with how to do user interfaces.   For example, there are different ways of presenting picklists.  Horizontal is compact.  Vertical could be used to indicate a more important choice (maybe).  A scrolling picklist shows extreme economy and can look "cool" (assuming it also isn't annoying though).

    There's also the issue of list fatigue.  If everything is a picklist, the user could get tired of seeing lists lists lists.


    Hick's Law

    "The more choices you present your users with, the longer it will take them to reach a decision."

    THAT makes me think that adding some wizard-like functionality at the beginning is a GREAT idea.  AND there's one other implication:


    One-thing-per-page.  This suggests I should always focus the content of the screen on the current task: if you are picking a jump drive, then I should only display the list of jump drive options on the page, and leave the clutter out.



    PETSCII is Horrible

    The reason PETSCII is actually not horrible is in the context.  Since this is a retro-based program on a retro platform, the PETSCII look and feel is actually an asset.

    "visually appealing interfaces are better, faster, easier"

    Paradoxically, to a small extent, the PETSCII nature of this program is a visual appeal to retro.

    Nevertheless, usability is still important.



  2. I have little to contribute, except that I have worked with I2C on the RPi, gathering data from an ultrasonic motion detector, and a range finder.  I found I2C on the RPi to be easy to work with, enabling fun.

    I've *seen* the SPI pins on the Pi as well, and I just assume it is also easy to work with. 

    Because I'm not a hardware guy, I look for Ease Of Use when it comes to hardware projects.  I can solder a header onto a Pi, if I'm careful.  That's about my limit.


  3. This is a UX-style issue.

    The trick in UX is finding how best to manage inherent complexity for the user's benefit.

    I'm asking for UX suggestions with a base assumption that this is PETSCII on the X16.  The rest of this post supplies context.


    I'm writing a game utility -- a design-your-starship utility for the Traveller RPG.  And I'm doing it in PETSCII on the X16, because that combines two of my favorite things (Traveller and the X16) into one effort.

    Starship design is underlaid by a set of line items, each item a component in a ship. Each component is selected from a picklist.  Thus a ship design minimally comes from ~12 picklists.

    I want to design an "ergonomic" interface for picking from those picklists.


    Define "Ergonomic" 

    Ergonomic, I think, has to do with how the picklists are presented to, and accessed by the user.  There is also the consideration of showing "progress" in the ship's design, kind of like ticking off items in a shopping list.

    Ergonomic ALSO has a lot to do with colors and empty spaces, and I am TOTALLY up for suggestions there!


    Mockup With Data

    A picture paints a thousand words.  Here's a working mockup.   On the right of the screen-shot is the "worksheet" with the current state of the ship being designed. 

    On the left is where I'm trying to decide what to do.  This mockup shows a "master picklist" of component categories;  presumably the user would select which component to work on, and program control would shift to a form based specifically on that component.

    But there are other ways to do it:  for example, the "master picklist" could in fact represent larger areas representing multiple choices -- for example, maybe there's an "engine room" choice that lets you manage drives and fuel, then a "defenses" choice for weapons and shields, and so on.

    I've attached that as the second image. 

    Something I don't think I can do is allow EVERYTHING to be choosable from one menu.  There are too many options for that -- hence, design has to be broken down into sub-areas.  Maybe it's just a matter of organizing those sub-areas into menus in a rational way that supports the user's thinking process.




  4. On 9/16/2022 at 4:23 AM, Johan Kårlin said:

    An idea is to have some official quality mark that can be given to software that meet certain demands. Those games/programs that are acknowledged can then have a certain title screen or badge in common. Compare for example how all Apple Arcade games start with a very short animated logotype intro. After that they all look very different. This could also be very motivating for developers in our community to make finished and stable products. 🙂

    Not completely unlike how Commodore used to do it...



  5. So when I went to click on the "WOW!" icon, I couldn't find one.  But I don't want to have to make do with "Like".  So...

    oooooo   oooooo     oooo   .oooooo.   oooooo   oooooo     oooo .o. 
     `888.    `888.     .8'   d8P'  `Y8b   `888.    `888.     .8'  888 
      `888.   .8888.   .8'   888      888   `888.   .8888.   .8'   888 
       `888  .8'`888. .8'    888      888    `888  .8'`888. .8'    Y8P 
        `888.8'  `888.8'     888      888     `888.8'  `888.8'     `8' 
         `888'    `888'      `88b    d88'      `888'    `888'      .o. 
          `8'      `8'        `Y8bood8P'        `8'      `8'       Y8P 
    • Like 1
    • Haha 2
  6. Is there a performance benefit to using 8x8 tiles over 16x16 tiles, if the same viewport size is used?  It would seem more efficient to blit one 16x16 tile than to blit four 8x8 tiles, but I don't know -- blasting sprites around certainly didn't feel performant.

    In other words, is it better to have an 8x8 view of 16x16 tiles, or a 16x16 view of 8x8 tiles?


  7. Alright, I'll start from first principles.


    The Tile

    A tile is a graphical object that is 8x8, 8x16, 16x8, or 16x16 pixels.  All your tiles are stored in a contiguous block of memory in VRAM. 

    Each pixel in a tile requires 2, 4, or 8 bits in the tile data, based on the color depth of the tile map. The memory required for each tile depends on the color depth and tile size:

    • 2 color, 8x8 = 16 bytes per tile
    • 16 color, 8x8 = 32 bytes "
    • 256 color, 8x8 = 64 bytes "
    • 2 color, 8x16 = 32 bytes per tile
    • 16 color, 8x16 = 64 bytes "
    • 256 color, 8x16 = 128 bytes "

    16x8 has the same memory requirements as 8x16

    • 2 color, 16x16 = 64 bytes per tile
    • 16 color, 16x16 = 128 bytes "
    • 256 color, 16x16 = 256 bytes "

    In this respect, tiles are just like small sprites.

    Set the Tile Base Address to point to the start of your tile data.

    The Tile Map

    A tile map is a list of tile entries. A tile entry has a one-byte tile index, a palette offset, and "flip" bits. Note that this means you can have up to 256 unique tiles in a map.
    Note that the color index in each tile is modified by the palette offset in the tile entry using the following logic:

    • Color index 0 (transparent) and 16-255 are unmodified.
    • Color index 1-15 is modified by adding 16 x palette offset.

    Set the Tile Map Address to point to the start of your tile map list.

  8. On 2/12/2021 at 2:27 PM, Johan Kårlin said:

    I have implemented this, but updating single columns and rows got unnecessary complicated. I ended up with a double buffered 32x32 tilemap (tiles 16x16). I scrolled 15 pixels and then updated the complete visible part of the tilemap. That made be spend about half of the available CPU cycles including all other code that was running each frame. A processor speed of 8 MHz makes a great difference compared to 1 MHz : ).

    Johan, can you talk about this a little more?   I understand the double-buffering, but it sounds like you have multiple copies of viewports?  So there's a viewport shifted one tile north, another that's shifted one tile south, and two more for east and west shifts?

    Oh no no no no.... you're using the inactive buffer to rebuild the visible map, and then switching the view coordinates to point to that.  Is that right?



  9. Here's my second stab:

    1. A real 6502.
    2. Commodore KERNAL
    3. 80-column VGA
    4. 64K main RAM, 512K banked RAM, and 512K banked ROM.
    5. 128 sprites, 16 voice stereo PSG, and digital sound.
    6. PS/2, SNES, and Expansion slots
    7. User port and IEC port


  10. X16 uses the Commodore RND(x) function, which uses that "x" parameter in specific unexpected ways:

    https://www.c64-wiki.com/wiki/RND      <-- I use c64-wiki for all my Commodore BASIC questions!

    RND(0) is never really a good idea.

    RND(-TI) should be done first for a seed... but first, have the user press a key.   This effectively randomizes TI.
    RND(1) is then used to fetch your random numbers.  And RND(1) or RND(17) or RND(92), and so on, all do the same thing, so RND(1).


    • By using RND(<positive number>) gives a different random number each time from a predetermined sequence (the sequence number is stored internally).
    • Using RND(<negative number>) jumps to a point in the sequence determined by the particular negative number used. Repeatedly calling RND with the same negative number results in the same result; typical use is to call RND(<negative number>) once and then repeatedly call RND(<positive number>).
    • With RND(0) the C64 generates the random number from the internal clock, though the possible values are limited as the digits of the clock only fall in the range 0-60, so it is not suitable for generating large ranges.


  11. I tell you, the Try It Now option is the BEST way I know of getting quick attention for something I'm working on in the X16.  It makes these little programs easily accessible to non-nerds.  I can post on a Facebook interest group and get immediate feedback.   Similarly I'm much more likely to Try It Now than to download a binary and run it locally.


    So how is Try It Now implemented?  Is it hard to migrate it to r41?  I mean aside from the huge pile of r38 code that will break when that happens...  But sooner or later it'll have to be done, right?  Is there enough current traffic on Try It Now, and not enough r41 development, so that we should stay at r38?  Should I be dual-compiling my binaries?


  12. PETSCII Space Invaders **currently a mess**

    View File

    Note the title:  CURRENTLY A MESS. 

    I am aware of it. Painfully.

    Without really thinking about how to get it done, I just sat down and started writing it, adjusting my C source as I needed to.


    Now it's time to rewrite it, probably from the ground up, and I'm looking for suggestions.


    I'm thinking I need a kind of text buffer for the invaders, which can double as a collision map.  Similarly for the tank.  Even the houses... heck the whole screen kind of needs a buffer.  It's only 4K maximum (and probably only 2K).  Otherwise I'd have to look at VERA to see if there's a collision, and I don't like the idea of doing that.

    But maybe a text buffer is a bad idea?


    And the sound -- ugh!  I am incompetent with X16 sound.  If only we had SID... Well anyway in order to do anything useful I'm going to have to have multitasking, and on the X16 that means I'm going to need some assembly running on an interrupt or something like that.  Which means I'm going to have to re-learn all of that.

    Am I sounding whiny?  Sorry about that.

    • Submitter
    • Submitted
    • Category


  • Create New...

Important Information

Please review our Terms of Use