Jump to content

Starsickle

Members
  • Content Count

    65
  • Joined

  • Last visited

Everything posted by Starsickle

  1. Yeah. I'm mystified. The main file clearly allocates more to memory in every regard than the data initialization file, so the explanation doesn't seem to fit. No matter what the case - I need to fix this, and I don't know how. Design wise, everything important is allocated, and if the program can't even correctly execute a random string literal after going back into main fail execution? I am clueless as to what to change or how to make this work.
  2. The good news: It works again. The game is playable again. The Bad news: I think only the DATA segment of memory is preserved between LOADs. So in this pic, you can see that some of the string literals did not survive, neither did any of the dimension-ed arrays before they were filled in the Data Initialization file. But...curiously: 3106 PRINT " RETROTREK - "VN$" STATUS: "SU$" RAM: "RF$ Of course, the debug output for ship data DID survive. Well, mostly. The IFFs did not survive, the ship names did not survive. Yikes. I happy the program can execute correctly, but now I have this new problem that defied expectations.
  3. Okay - this is an easy fix, then. I just cannot have a 0 state when this is first starting.
  4. Problem with the switch statement from earlier: 21 ON CS% GOTO 25,1500,2000,9997,30000 22 GOTO 31110 Presumably, you cannot initialize CS to 0 because once the file is loaded, CS is overwritten. but what happens right now is that the program slips through to 22 (Error). If 22 was not there, it slips to 25, which sets CS to 1, and eventually leads to a REDIM error. How do I use this correctly? Apparently the implicit 0 does not trigger 25...
  5. This is how I'm doing it. I have plans for a full color mode someday, but today is not that day. For now, I simply GOSUB to invert colors, but storing as 4 variables makes it more obvious what's happening. 10 FC%=5 : BC%=0 : FI%=0 : BI%=5 : COLOR FC%, BC% 70 REM //SUBROUTINE - SET COLORS TO STANDARD 71 COLOR FC%, BC% 72 RETURN 73 REM //SUBROUTINE - SET COLORS TO INVERTED 74 COLOR FI%, BI% 75 RETURN For me, important cursor positions for LOCATE are documented within each subroutine. What's more valuable - A REM line of documentation or N pairs of integer variables? You at least need the upperleft corner of each window you write characters in, right? Your MFD window is very large for something that is presenting options for the player. You have about 24 characters of room before an even border with the top windows. Split that window, and make the lower right a text spam message queue or a some window to present description or data. Perhaps a mode tracking variable for the menu state you are currently in, and after that just use "1110 GET A$: IF A$ = "" THEN 1110" and more to control the input handling immediately instead of risking errors. In UX thought - every action (even in error) the player takes should invoke some kind of feedback from the game - so that has to go someplace.
  6. HAHA! Awesome, here's some thoughts on the idea. First, the acquisition of the file should be as straightforward as possible, incur as little trouble to the game as possible, and be as temporary as possible. So, the way I see it is this - the user, having various usernames, constructs a mailbag of messages to be sent out whenever they want. This is an asynchronous activity, after all, so we need to support asynchronous methods. They package up their mail and send it out. Users can download this file and read it into a mailbag, after which they go through it if any messages are for them. (Key needed, of course. Beyond my experience.) Once the incoming mailbag is done being looked at? The file is useless. Repeat for more fun. Making it one way eliminates any need for keying, meaning that everyone's messages are for everyone else, which opens up other gameplay options for reading mail and acting on it. Perhaps some keys or options will trigger events in a local game? Up to you. Now, this of course opens up a huge cheating hole, but hey - it's not like we're aiming high on security - just simple communication. To summarize the player experience: Go to Comms terminal Make new message for mailbag. Add Username, message, Gameplay Things - whatever you'd like. Commit mailbag. User uploads the file. Downloads a incoming mailbag. Open Comms Terminal. Check Mail Read any messages, gain benefits. Incoming mailbag disposes itself.
  7. Optimization question: Pic below needs some work, as it takes up many lines in the program and requires several helper methods and variables. I'm not sure if I should store some elements as dedicated string variables or not, because I'm unsure if it will save space, especially if I end up sending the screens like Game Over, Mission Complete, and similar into subprogram files along with their helper methods.
  8. This is what I'm considering for the main file, although there's some concerns with how this will work. 15 MC%=0 : REM //THE MASTER COUNTER - USED FOR PROGRAM JUMPING. 16 LS%=0 : REM //LOADED FILE STATE - CONTROLLING THE LOADED FILE. 19 REM // DEPENDING ON GAME STATE: INIT DATA, MAIN LOOP, EXTRA, TERMINATE 20 ON LS% GOSUB 28,1000,1000 The Master Counter will increment every time a file is jumped. This will help me determine if the program is functioning properly. It's not needed, as I originally thought I could use MC to control or save a line number. The Loaded File State is the important one. This determines the program state, and when any given program file is loaded for execution into Low RAM, it HAS to hit a check versus the state first. So - what's wrong? The fact they are defined above. I think I could move those down into GOSUB 28 (which is implicitly LS%=0, right?), but now the problem exists of the following: A lot of this program is broken up into subroutine pieces and helpers. If I overwrite the program every time I load a new file, I have to make sure I make several pieces redundant, or only include them within the file loaded for execution. This is very big design challenge, because one has to remember not to overwrite important pieces of data that remain in the appropriate Low RAM stack. Outside of that challenge? Well, there is an alternative, but I don't think it's possible - I could load the program entirely into High RAM, but I don't think it's executable from that area, as it's simply not segmented like the Low RAM. This would be an interesting ability, though. EDIT: I also am not sure about how to capitalize the title - feel free to choose between RETROTrek, RetroTrek, and RETROTREK.
  9. I'm looking it over - the hardest part of all this really is that everything is in 2 letter variable names - but I can see you start at the starting address (AD) and allocate a specific amount of bytes to the name (24). First poke unknown - assuming it's a sentinel value or some other control value. Next is the quick ship profile, which is a Single character Archetype with 5 characters (uhh, a few have 6...). This is pretty slick, as it can be used for more procedural generation and representation. After that we're jumping around a bit, but CHR$(48+X) I assume is just navigating the character Table. Otherwise everything is a record of N size, controlled by LN for the line, jumping to a new AD because you know the size of each record in terms of characters and integers. If you don't mind, I'd like to try my hand of recombobulating this so I can store my own ship information, which currently looks like so: 41100 REM //SUBROUTINE - STARSHIP NAMES AND IFFS - ===========TODO - MOVVVEEEEEE 41101 SID$(0,0) = "ENDEAVOR" : SID$(0,1)="ALLI" 41102 SID$(1,0) = "NME-1" : SID$(1,1)="KLRG" 41103 SID$(2,0) = "NME-2" : SID$(2,1)="KLRG" 41104 SID$(3,0) = "NME-3" : SID$(3,1)="KLRG" 41105 SID$(4,0) = "NME-4" : SID$(4,1)="KLRG" 41106 SID$(5,0) = "NME-5" : SID$(5,1)="KLRG" 41107 SID$(6,0) = "NME-6" : SID$(6,1)="KLRG" 41108 SID$(7,0) = "ASTORIA" : SID$(7,1)="ALLI" 41109 SID$(8,0) = "RET-1" : SID$(8,1)="INDA" 41110 SID$(9,0) = "MERCH-1" : SID$(9,1)="DORA" 41111 RETURN 41120 REM //SUBROUTINE - SHIP DATA DEFINITION - SEE README ================ 41121 DATA 3, 3, 90, 3000, 18, 0, 300, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41122 DATA 1, 1, 30, 1000, 6, 0, 100, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41123 DATA 2, 2, 60, 2000, 12, 0, 200, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41124 DATA 3, 3, 90, 3000, 18, 0, 300, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41125 DATA 1, 1, 30, 1000, 6, 0, 300, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41126 DATA 2, 2, 60, 2000, 12, 0, 200, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41127 DATA 3, 3, 90, 3000, 18, 0, 300, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41128 DATA 3, 3, 90, 3000, 18, 0, 300, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41129 DATA 2, 2, 60, 2000, 6, 0, 200, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41130 DATA 1, 1, 30, 1000, 6, 0, 100, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0 41131 RETURN If I learn how to do this (and make it work), I definitely could just throw all the object data in the game into segments of a 512k High Ram Bank. Reading sequentially is a pain and N data lines grows, but perhaps, in known and well-defined cases, an ID can be assigned that matches a memory address for direct access, sorting, etc? Would love to have this sort of layout with the ability to highlight and select a line by inverting the color of the currently selected line. This is why I have colors set in variables along with their inversions.
  10. Starsickle

    Discord

    Nice! I was about to ask if there were plans for a discord once some things got rolling. If the moderators here are on top of it, this will hold us over until an official one can be made.
  11. Let's say you want ALL OF IT but still want the circle. AND let's say you want to simulate the world turning in the view: Place a circular mask over the planet's displayed map. Now rotate the displayed 2x2 array by shifting along x every whatever frames
  12. "There's no such thing as a perfect map." Once you can accept this, you gain some power over how you can present it. Take a look at Dwarf Fortress - it provides 3 key map views when selecting where to embark: The first is the large world map, which compresses down to a smaller map, which represents a local map, which then represents the actual map in game when you travel. I'd say stick with the rectangular map, but structure the system to be able to take a given character and a string seed and somehow precess that into a map. Since it's procedural, the same input produces the same output. Character + SeedString = the same map every time representing the same key type. This requires oodles of work, but this is how you avoid storing enormous amounts of information.
  13. Coming out of CS and programming, I'm the guy that wants everyone to document and tutorial everything, even for development. Over and over you can see that when the energy is spent to make things easier, a platform flourishes. I'd volunteer to the a wiki or a github, but there's a lot that remains unsettled and there's just some things I don't know right now. I DO plan on posting whatever tutorials I can create myself once the program matures into a small engine for content, but getting to that point will take time. I have years of experience in Java, years of experience in scripting languages, and the most important part of that is having mature code laying around to be copied and pasted. Heh. Maybe I should start a java project and see what can be done in two weeks with AWT/Swing, which I've grown quite sick of in Eclipse...
  14. Will do - this is much like a Switch statement? This will save many lines, and thus many bytes.
  15. As someone who still has Modtracker on Windows, I salute your effort and hope you can keep going with any kind of chiptune tracker on this platform.
  16. That's beyond my practical experience and understanding. (I see those graphs a lot, but I'm only half sure how to read them.) I am not good at systems-level allocation and Read/Write. I'd take up 40kb making sure the code for putting a single ship into and out of a stack was usable by my own self. Of note for consideration for features, though, is the way that The C64 and BASICV2 stores strings versus storing character arrays. This should be the subject of careful consideration for the X16 and C64 sharable code, as being able to cap various string into character arrays in a practical way means that you save memory. Much like we have Byte, Short, Int, and Double in higher level languages - so it should be with Characters and Strings on these lower level systems. Of course, there is the system's requirement for compatibility, but I'm at the point where I won't compress things any more in order to maintain readability without documentation. I don't even really know how to read and write data and files to any given filesystem. (My early tries in the EMU did not work). I'm basically going to wait until the GitHub Issues requests are designed and built and someone does some more key work before I dive back in. Someone has to do the system-level work that people like me can take advantage of. It's just not our bag. Immediately, the program needs its execution broken up into module files as much as possible so they can run in sequence. I grasp how this can be done, and it goes something like this: This here would be a data allocation and static data init file: 14 REM // MC% //THE MASTER COUNTER - USED FOR PROGRAM JUMPING. 16 REM // LS% //LOADED FILE STATE - CONTROLLING THE LOADED FILE. 20 DIM RGN$(3,3,3) : DIM SCTR$(3,3,3) 21 LS%=1 22 END which is called by the main program file below: 15 IF LS%=0 THEN : GOSUB 100 : REM //DATA NOT LOADED. 16 IF LS%=1 THEN : GOSUB 200 : REM //DATA LOADED, PROGRAM NOT. 17 IF LS%=2 THEN : GOSUB 1000 : REM //PROGRAM LOADED. GO MAIN LOOP. 18 GOTO 4000 100 REM //ROUTINE - LOAD ANOTHER FILE AND INIT DATA. 101 LOAD "INITDEMO.PRG", 8,1 200 REM //ENGINE SETUP AND INITIALIZATION===================================== 201 VN$="0.0.1" : VD$="SEPTEMBER 15TH, 2020" 202 FC%=5 : BC%=0 : FI%=0 : BI%=5 : COLOR FC%, BC% 203 SX%=640 : SY%=480 204 DIM GD%(3) 205 LS%=2 206 GOTO 1000 1000 REM //MAIN LOOP 1001 PRINT "DISPLAY SCREEN" 1002 PRINT "GET INPUT" 1003 PRINT "PROCESS INPUT" 1004 PRINT "LOOP" 1005 GOTO 1000 3000 END 4000 STOP This is janky as hell, but I otherwise don't know how else to quickly manage program execution other than a counter or a control state variable that always hits the top of a given program file. During this, there's so many potential hazards in the program section of memory, in the call stack of memory, and all of that that I just don't know what's going on with the machine to make a safe, solid call about designing a program that is only limited by the media it's being loaded from. I've returned to other projects, but I want to keep checking in on the X16. This kind of work is beyond my capability and patience. I don't want to give up, but I don't know if I can seriously continue short-to-mid-term.
  17. Entirely possible given that Nintendo already did exactly that with the 6502, but who would make software for it and why? Would you make it easier to produce performance software? Would you make it easy to distribute software? Would the 6502 be powerful enough to realistically handle a modern internet connection?
  18. I tried converting a 640x480 picture, but while the preview image seemed to check out, the resulting file that I saved had a size of 0kb.
  19. Not the best screenshot, but here's the last time it worked without running out of memory: I was just about to get the Mask and Player Position "@" working.
  20. Honestly, if the workflow in C is nothing more than do what I do in C Projects? Shove it into some machine - get a PRG file? I might consider it. But I would want ALL of C. All of it. Checking the video; it's promising, but I'm uncertain. I have a little experience with C, but my experience was rife with environment setup and workflow problems than actual design and programming. Thus is the destiny of Windows C/++ development without an IT department. I think, at least for now - I'm best served IRL by waiting on the design and engineering issues at hand before diving any deeper.
  21. Yeah, another consequence of having arrived a bit early to the party. There's still a lot to be designed and built, and maybe, in my own amateur-hour-millennial way - can help through suffering - that's fine. XD Not the place for this, BUT since it's relevant to the immediate problem: 1 - This would be ideal. we're dealing with 512K, so we have plenty of room to create intermediate structures for managing segments of addresses and thus data. The Low Ram presumably already does this (The C64 certainly does) - so why not allow the High Ram to do the same, if the programmer wishes it? It's the most novel resource of the machine. In essence, asking a bank to act in a similar manner to the Low Ram isn't a stretch in terms of design. 2 - Probably solved by some method related to 1. 4 - Yes. If you can solve the type enforcement, you automatically have the path towards running commands directly on higher ram. I'd throw this on the issue posts, but I worry that I might be a bit out of my own depth and the comments unwelcome. As for RetroTrek itself, I'm kinda halted except for small things. I'm currently implementing things in an untested state, namely combat mechanic functions like checking if the shields are down, damaging a random system, etc. The bottom and top bars are much better now; they and the SYSTEMS panel now have lots of useful information. The top bar now shows the current RAM free. It seems like, as soon as this is over, that things like generating the sector map will be easier, but expensive and slow. I will want something to display "PROCESSING..." while that intense stuff goes on. I am wondering if I can make a standard for subroutine inputs and outputs such that it uses the fewest variables but takes the fewest lines/chars to document in-code.
  22. Oh...nuts. That's not good. So, at current, there's no way to simply reference a bank and a name? So, if I wanted to continue, I would need something to reliably read....some place within a given bank and bytewidth in order to properly cast information and return it. So, something like: 10 REM //SUBROUTINE - BANK ACCESSOR 20 REM //INPUTS - B% - BANK #, A% - ADDRESS?, W% - BITWIDTH, 30 REM //IFS ON W% BEING 1,2, OR 3 ASSIGN R AS RETURN AND RETURN 40 RETURN Yeah, so This means I need documentation on both the banks used, the memory addresses statically assigned, and - basically no dynamic assignment or allocation or names within the banks. Lame. Depressing, even. I will have to cut features.
  23. How do you consistently wrote out Capitalized and non capitalized text to the screen? That looks so nice and readable! Also - how do you manage and store what I imagine to be a lot of descriptive text? Would love to know this, as my games are mostly text heavy and, as you can see - I'm running into some "problems of scale". As for the game - that looks great. I imagine it's going to get complicated, so maybe eliminate some labels and prompts for a Help Screen? You can also fit either more text or more skill stats into the block below the backpack. Definitely looking forward to seeing how this ends up.
×
×
  • Create New...

Important Information

Please review our Terms of Use