Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. I've thought about porting a light, PETSCII-friendly version of AWK into a "X16 Shell"-like thing.
  2. LOL you had me going there until after the nine bit system. Regardless, I'm not worried.
  3. Ha! There's a final release? I'm behind the times... please stand by.
  4. Since most of my X16 coding is in C using cc65, it's a given that I use cc65 for what little assembly I do.
  5. UI REBUILD 08: REFUEL This is a late addition -- the ability to refuel from either the mainworld, or a local gas giant, or asteroid ice, or oort cloud ice. The latter two don't have "artwork" yet. The mainworld and gas giant are procedurally generated, and so are slow but not horribly so, and result in the same pattern given the same world data. Again, this screen would benefit from borders.
  6. UI REBUILD 07: SHIPYARD This is where you trade for another ship. This used to be a flat list, but instead I went to a page-flipping scheme where you see ALL of the stats for each ship on the entire page. It's great for when you need detail -- and when you're ship shopping I figure you need detail. HOWEVER... I started out with as much detail as I could fit into a 48 byte structure, in order to give me options. Now that I've filled up system RAM, I'm thinking there are some details which are not important. I'll have to think about that for a long time of course. One major thought I've had lately is that I shouldn't list a ship unless I have an icon for it. This limits my number of ships down to maybe 19 ships... maybe two dozen if I get a couple more designs squeezed in. I currently have maybe 46 ships, and I think there's sufficient overlap still, so this is probably OK. I have over a hundred unique ship designs on hand, but their differences aren't necessarily large enough to be important.
  7. UI REBUILD 06: THE HIRING HALL This bit works well, but has some problems. If I'm moving to borders, it needs borders. Needs a little prettying up. The colors are perhaps too muted. Maybe an icon would be nice here. The menu doesn't work like the others. I either need to use the standard menu system, or else make this one look and act more like the others.
  8. UI REBUILD 05: STARPORT The starport is where you repair and upgrade your ship. This needs to be more engaging, centered, nicer... right now it is a mess. I have no idea why I put the ship's data line at the top of the page, either. Most of that data has nothing to do with repair and upgrade.
  9. UI REBUILD 04: TRADE The trade menu is still fairly primitive... it's not centered, and the colors are too dark. Also, if I'm using borders, I need borders. I plan to use Tom's mockup as a guide for improving it.
  10. UI REBUILD 03: MAIN MENU This screen suffers from not really being anything other than a dumping ground for actions. It currently holds details of the source and destination systems, but it's not really an appropriate place for these data. It IS convenient to know that a destination is set, but I don't know if the full details are important here. Second, the current and destination worlds need to have borders, as does the alarm bar. Third, like Tom's mockup, I'd like the game's name on the page -- maybe at the bottom.
  11. UI REBUILD 02: ASTROGATION This will be the fourth re-imagining of the astrogation interface. My assumption is that a player would enjoy moving a reticle on a small piece of the big map. But, I'm not longer quite so convinced that it's a good idea. I also suspect it takes more main RAM than a list -- after all, there is placement code for the features of every system in the view. But I don't know if that's a major concern; I don't think it would make more than 1K difference. Here's the current view. And here's what I am thinking: If I keep this interactive map, then I need to center it, put a border around it, and find a reasonable way to represent the "metadata" on the left side. Replace the map with a short but expandable selection list (per Tom's suggestion), and include the current + destination system details in this view. I'm currently leaning towards #2.
  12. UI REBUILD 01: SPLASH SCREEN First is the splash screen. It is one of the most recent additions to the game, and I *think* it's okay borderless..... except for the menu, which I think needs a border, and also needs a one-key selection scheme. RESULT: WOW... yes the one-key selector is WORTH IT. But I have to ask myself: do I really need an experience level? I use it to gradually introduce game controls. But... is that really necessary? Does it actually make it easier to learn the game and the game controls? I remember where this came from... it came from a guy's blog that I read a couple months ago. He said that graduating players from the basic controls into increasingly powerful controls can be like a rewards mechanism. It's better, in other words, than an "Advanced Mode" switch, or piles of help screens (but nothing replaces good documentation). So then, this initial menu is to allow veteran players access to more controls, while giving beginners an easier onramp. I guess it's justified.
  13. Tom mentioned something: That is a fantastic idea, and in fact I know how to do that really well: There's an entire scrollable, searchable map application + API online, courtesy Joshua Bell: https://travellermap.com/?p=-94.629!71.141!7&options=57599&ew=1310&qz=1 A player could simply use that to plot a course. But it also has a poster-maker, with which I can create two PDF maps to include in the documentation bundle (attached). Deneb.pdfSpinward_Marches.pdf
  14. I'll take this to the Traveller Trader WIP thread.
  15. I need to simplify the user interface for two reasons: (1) the game feels too complex. (2) the game uses too much RAM. I'll follow with screen shots to explain what I'm thinking.
  16. When I try to mock up my Traveller Trader, I get a little bogged with the vast number of choices. Which makes me realize I need to pare it back -- that there's a lot here that's not important. Also, in some cases, I just need to manage the data better.
  17. MacOS. I'm seeing the top pixels cut off a bit in 41_rc3, e.g.
  18. Can I use PLOT to position the cursor and then use a PRINT to print the text at that position? What I'm seeing is that I can set the Row, but the column is reset before I do the PRINT: 10 POKE $30C, 30 :REM ROW = 30 20 POKE $30D, 40 :REM COL = 40 30 POKE $30E, 0 :REM CLEAR FLAGS 40 SYS $FFF0 :REM PLOT 50 PRINT "HELLO THERE" :REM PRINTS AT ROW 30 COL 0
  19. But then, there's also this. I2C $FEC6: i2c_read_byte - read a byte from an I2C device $FEC9: i2c_write_byte - write a byte to an I2C device Function Name: i2c_read_byte Purpose: Read a byte at a given offset from a given I2C device Call address: $FEC6 Communication registers: .A, .X, .Y Preparatory routines: None Error returns: .C = 1 in case of error Stack requirements: [?] Registers affected: .A Description: The routine i2c_read_byte reads a single byte at offset .Y from I2C device .X and returns the result in .A. .C is 0 if the read was successful, and 1 if no such device exists. EXAMPLE: LDX #$6F ; RTC device LDY #$20 ; start of NVRAM inside RTC JSR i2c_read_byte ; read first byte of NVRAM Function Name: i2c_write_byte Purpose: Write a byte at a given offset to a given I2C device Call address: $FEC9 Communication registers: .A, .X, .Y Preparatory routines: None Error returns: .C = 1 in case of error Stack requirements: [?] Registers affected: .A Description: The routine i2c_write_byte writes the byte in .A at offset .Y of I2C device .X. .C is 0 if the write was successful, and 1 if no such device exists. EXAMPLES: LDX #$6F ; RTC device LDY #$20 ; start of NVRAM inside RTC LDA #'X' JSR i2c_write_byte ; write first byte of NVRAM LDX #$42 ; System Management Controller LDY #$01 ; magic location for system poweroff LDA #$00 ; magic value for system poweroff JSR i2c_write_byte ; power off the system
  20. I just read about this X16 KERNAL function, and thought it would be useful for an efficient file transfer mode: Commodore Peripheral Bus The X16 adds one new function for dealing with the Commodore Peripheral Bus ("IEEE"): $FF44: MACPTR - read multiple bytes from peripheral bus Function Name: MACPTR Purpose: Read multiple bytes from the peripheral bus Call address: $FF44 Communication registers: .A, .X, .Y Preparatory routines: FILNAM, FILPAR, OPEN, CHKIN Error returns: None Stack requirements: ... Registers affected: .A, .X, .Y Description: The routine MACPTR is the multi-byte variant of the ACPTR KERNAL routine. Instead of returning a single byte in .A, it can read multiple bytes in one call and write them directly to memory. The number of bytes to be read is passed in the .A register; a value of 0 indicates that it is up to the KERNAL to decide how many bytes to read. A pointer to where the data is supposed to be written is passed in the .X (lo) and .Y (hi) registers. Upon return, a set .C flag indicates that the device does not support MACPTR, and the program needs to read the data byte-by-byte using the ACPTR call instead. If MACPTR is supported, .C is clear and .X (lo) and .Y (hi) contain the number of bytes read. Like with ACPTR, the status of the operation can be retrieved using the READST KERNAL call.
  21. THINGS I DO LIKE Lest you think I hate my work, there's a lot I am proud of. (A) Data management. I have so much binary data stored in RAM banks -- especially the map, and the starship list. Both of those are large: the map is a couple hundred K, and the starship data is squeezed into one 8K bank. The map just won't fit in system RAM. Other banks are used for other "nice to have" things that run from 1K to 8K, and each of which would potentially limit the main program. (B) Navigation. The ability to jump correctly through a hexmap of "space" from system to system is a major accomplishment for me, and I'm very happy with it. A sprite reticle is pretty cool, too, although it might be incongruous to the retro feel. (C) Data representation. Going back to data, it took a long time to figure out what data was important for the game -- I couldn't just store every known piece of data, and I do rely on some bitfields. The result is a satisfactory tradeoff of terseness versus completeness. (D) Ship crew management. The menu may need improvement, but the crew naming, hiring, firing, and "automatic" skill use is good enough. (E) Ship icons. They seem a little incongruous to the retro nature of the game, but having good-looking ship sprites was a big accomplishment for me. (F) The alarm bar. Having an alarm bar carry ship overall status is something I've had since the BASIC version. It's terse and retro and concise and useful... it even lends some drama to the game, especially if you see a lot of critical alarms lighting up your screen.... in theory. Assuming I ever get combat written.
  22. THINGS I DON'T LIKE I let this project rest for a couple months while r39, r40, and r41 came out. I looked at it again, and compared its look-and-feel with two other attempts: (1) Tom's "Space Trader" mockup menus are better. Tom's mockup has a very clean and functional look. Its menu sample is superior to my scrolling-selection menu system, which is slick but less usable. More subtly, my menu code encourages poor design choices, such as longer menus to choose from. I suspect the ideal menu size is 5 to 7 items. If it's got more choices than that, I need to rethink my design at that point. (2) My earlier BASIC version of my trader game looked PETSCII retro nice. My earlier version had clean-but-retro, rounded PETSCII borders. It split the screen into clear zones, and data was compartmentalized and summarized in an engaging way. At least, that's what it seems to me. It still relied on the scrolling-menu theme, which I don't like, but otherwise the overall look was ... well I have to repeat myself and say it looked engaging. (3) The Trade Engine. I am working on a third trade engine. This one follows Traveller's Book 2 to the letter. I don't know if it's going to work out. (4) Combat. I am not sure how to do text combat well. What I *DO* know is that it can't be long and drawn out, and it must have very limited but important options.
  23. It's all in C, using the cc65 compiler.
  24. So Tom showed us his "wireframe" menu for his Space Trader game. If you didn't see it, it uses the new 80 x 30 display mode reminiscent of the C128 -- and it looks clean and classy. But I wanted to comment on his menu system. If you just look at it, you know exactly how to work it -- it's the classic "one key, one option" thing. Thus every visible menu option is one keystroke away. The color scheme is pleasing as well, but not a show-stopper if you're colorblind. I think that's an optimal, usable way to do menus on the X16. ---- On the other end is my Traveller Trader game. I opted to go with a scrolling-menu system. This means the user has to "cursor" to the desired option. It's not as usable. It's helpful for when there are many options, and I only use one function to render and manage all menus -- that's how I argued the decision to myself. But... there probably ought not be dozens of options in any given menu. And scrolling is not a fantastic experience. So, +1 for the one-key-menu.
  • Create New...

Important Information

Please review our Terms of Use