Jump to content

rje

Members
  • Posts

    1262
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by rje

  1. My commit levels have been at a lower level, but relatively consistent since December 2020 or so. I just seldom finish anything LOL
  2. Maybe. 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.
  3. 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.
  4. 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.
  5. Very true. Now, $300 still sounds like a lot of money for the project, and I'm always looking for the cheap angle. I'm still thinking about that Raspberry Pi 1581 emulator.
  6. Not completely unlike how Commodore used to do it...
  7. Oooh I like an "Official X16" style... A sprite that looks like a sticker??
  8. I was kind of bummed when I read that TI isn't working! I mean it's required for RND() to work. I'm glad it works in r41 though.
  9. 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
  10. Oh wow, does it??!! LOL Huh works over here. Maybe it depends on the ... well what? The hardware the emulator runs on??
  11. You're worried about consistency of the splash page? With hobbyists and amateurs like me?
  12. 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?
  13. Alright, I'll start from first principles. TILE MODE ON THE X16 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.
  14. I'm thinking C will actually be easier than BASIC, even with a simple case.
  15. Subtle point? I'm not sure I know the difference.
  16. 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?
  17. Here's my second stab: A real 6502. Commodore KERNAL 80-column VGA 64K main RAM, 512K banked RAM, and 512K banked ROM. 128 sprites, 16 voice stereo PSG, and digital sound. PS/2, SNES, and Expansion slots User port and IEC port
  18. rje

    Bill Leue

    Welcome Bill! Us developers gotta stick together -- this forum has lots of hardcore assembly programmers!
  19. 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).
  20. Ah, see I didn't know that. Thank you.
  21. 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?
  22. 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 rje Submitted 08/23/22 Category Games  
  23. Version 0.0.1

    53 downloads

    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.
×
×
  • Create New...

Important Information

Please review our Terms of Use