Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral

About Starsickle

  • Birthday 06/09/1983

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Okay - so this is basically LOAD "FILE", DEVICE, BANK, ???? And - to close that circle - how do you access things that you put in that bank? (I have a feeling my question thread now contains this - just humor me) If I can get this understood and successfully demoed for myself, I can redesign the program and REALLY have some room to work with, as well as organize the code much better with full documentation. I'm not used to being so formally punished for doing (what I consider to be) a good job! XD
  7. This is potentially helpful - I could very well just fracture off engine initialization (Screen sizes, etc.). Then DATA INIT runs and all the program's data can be allocated, read, and initialized. That sends it back to the main, where a control variable (as in the wiki example) now sends control to the main game. The main game reads the control variable as a stateID. The potential problem here is going back to the first might accidentally reset some variables because they are initialized in good practice at the start. I will try tinkering with this. EDIT: This is the example I'm working on. STARTDEMO.PRG 16 REM // LS% //LOADED FILE STATE - CONTROLLING THE LOADED FILE. 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 And one of its potential compantions - INITDEMO.PRG 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 How's that?
  8. So, let's say I were making an engine. I could basically allocate the variables that I'll always be using in my programs anyways then LOAD the actual program? That could be worth the code savings. START.PRG INIT.PRG GAME.PRG It's possible I might just have arrived too early and these features may come to be, but considering we have the potential for unlimited program space on media - this would be a very powerful capability if were to be figured out.
  9. So, this is something I will need out of necessity (1120 lines and currently at 44kb) and not entirely sure how to do by just looking at the C64 wiki. It describes how LOAD may be used, but only at the start of a program with little description of how this saves Program Memory or can benefit Program Flow. Let us say we have a fairly large program and want to break up its raw number of lines to keep memory free. What essential components do I need to tell a program to LOAD THIS, DO THIS, and then GO BACK WHERE YOU WERE? Basically - I'm aiming for the framework to execute a GOSUB but with a file. That way, within the program framework, I can offload... PROGRAM START SYSTEM SETUP DATA ALLOCATION DATA INITIALIZATION (THIS) MAIN LOOP START DRAW (THIS TOO, BUT SPECIFIC) INPUT PROCESS (AND THIS - BUT SPECIFIC PROCESSES/OPERATIONS) CONTINUE MAIN LOOP END PROGRAM TERMINATION Perhaps I just need an illustrative example. It's not apparent LOAD can be used this way, as it "returns to the very beginning" of the originating file. https://www.c64-wiki.com/wiki/LOAD Thanks in advance.
  10. At this point, I've hit the memory ceiling and cannot code further unless I solved this problem. The program is too big. The best thing to do is to LOAD and RUN a separate program and RESUME where the program left off when the subprogram finishes executing. This is not something I know how to do in BASIC V2, though it was easier to solve in SMILEBasic, where I had 6 file slots and would run the main loop in 1, data and core in 2, Map and Input in 3, and Content loading and swapping in 4 and 5. If I understood the code necessary to do this in this language, I could do this. I'm not a stranger to The Game State Machine. But, it seems my general design in this one-file-wonder that takes place mostly on a single screen is going to have a lot of trouble, as the game never really changes state. How do I save the most code space loaded into memory for execution and smoothly drop into and out of subprograms? I definitely could use some wisdom and instruction on this. Currently, the one-file-wonder is organized as so: The current tasking for this involves removing the 3000 series screens, since they are entirely separate screens and terminating game screens. This would similarly be done with anything currently occupying blocks that are just static data initialization. Sadly, I don't know if I could get away with it, since it DOES mean all that program still needs to be loaded into the precious Low Memory. A more elegant design might have me able to take the longest Subroutines and create them as programs - effectively turning a loader into the equivalent to a GOSUB. That would be best. This means I have unlimited power on the filesystem, since our filesystem has no conceivable limit in size other than the media. I am not experienced enough to really understand good, clean, organized design on this platform, so at this point I could use some wisdom and examples. In the meantime, I pitter away at small tasks and spend time cleaning code in preparation. I want a 0-1999 Segment that I can copy paste into anything, and I'm fairly close to having that complete as soon as a few more code cleanups are finished.
  11. https://www.c64-wiki.com/wiki/Garbage_Collection Oddly enough - a potential answer in Garbage collection. So, there is a solution here which might have diminishing returns very quickly. Every time I make a string in code, the descriptor points to the program, where it's already been stored. This gets large very quickly, but what I'm fuzzy on is - does it ever get UNallocated, for example, when exiting the scope of a GOSUB after RETURN by the garbage collector? If it is, then the cost of pre-allocating often used strings is cheaper than defining them in the code (alike above). That is one direction I could take. Sadly, I don't know what exactly I'm running out of - There are segments of memory dedicated to pointers and segments that contain their contents. Given the state of the program right now, I have have lot of strings defined in code. What I think I need right now is a way to get the total size of a segment of memory (the string content, most likely) and give myself an in-game meter in order to watch. In the midst of that little task - uh oh: EDIT 2: ......................................Comments. The memory usage in a program includes the space taken by remarks. Wow. Just wow. After deleting some documentation, I was back under the limit and able to play. I have to delete and compress all of the comments in this file, and I know there are still thousands more lines to this program when it's done. Well - that is pretty devastating. I'm not even a third of the way done. EDIT3: Well, after some much-needed sleep - the answer lays within the ability to save program code space by swapping files and eliminating code from the main file to another file to be loaded and executed before popping back to the main loop. I know how to generally do this elsewhere, but not in BASIC V2 on the X16. How this is done without ruining the process or the program counter and making it as easy as functional programming - well - it feels a bit out of my league right now, but I'm not going to wimp out. I just need to understand how it's done cleanly within the loop of DRAW, INPUT, UPDATE, and returning to the main screen so the user can play. I could use an example game that is using multiple files to manage its game state like this and how I could package it on a file system.
  12. Rough day. Good news is that another Code Cleanup is complete, but the bad news is that I've reimplemented Move, Warp, Scan, and Fire as far as I could take them - and was about to see how the Regional map printed out on generation but ran into the memory problem again. I commended out Sector - expecting to use High Ram for that, later, but unfortunately - I was so close to finally getting a shot of the revealed map instead of ???? when I ran out of memory again - this time inside a lowly subroutine to print the bottom bar. Out of Memory again. This cannot continue. I need a better way to store everything, or I need to find new ways to handle individual characters or not store as many strings. Case in point - the way screens are drawn. These are stored as strings. Strings that I really don't exactly know where on the X16 low memory they are stored on the stack or when they are garbaged. The top line is a 80 character string. The bottom three bars are 3 80 character strings. The title screen is therefore some amount of string descriptors and some amount of arrayed characters in the assigned memory space - resulting in about 4234 bytes, or otherwise 10% of our available memory space before whenever the garbage collector gets to remove the ones seen in the screen. This is my best opportunity now to handle this without understanding how to write to a specific bank as easily as I write to wherever. I'm clearly at a stopping point, and I need to crunch my memory usage because what is currently allocated shouldn't be swapped out of memory unless I want a LOT of very interesting glitches or bugs to appear down the road or find some way to always safely process-out the swapping of banks between calls. It's time to stop coding and start reading, as the memory limit is preventing me from testing and making pushes forward.
  13. @TomXP411 Thanks - I'm a bit groggy, but let's take a look: For clarity, the special region is as posted above: 10x20 with 10x10 sectors. the real problem is storing the data associated with them either as tables or as the third index. I'm opting for the third index, but this DOES explode memory cost. What you are proposing is pretty technical and I don't have much experience with it. I would prefer to wait for the keyword to be finished before hammering out functions to bitwise poke into the X16's novel memory banks. Of course, I'd also ask for the interpreter to recognize the character format, as I'd be perfectly happy NOT wasting what seems to be the C64's method of allocating strings when I could just have characters. That said - I could probably use some amount of banks for the 200 sectors. Sleepy-brain-without-coffee tells me that's quite a lot of contiguous memory, and I'm having a hard time visualizing where it's going because I've read some things. http://microheaven.com/FastC64Basic/tips.html (ASIDE: "Don't do bubble sort" kinda tickles me) For now, at least, I'm back up and running having cut (9,9,9) to (9,9,2) and (9,19,5) to (9,19,2). Unfortunately, I'd also like to add information to tag objects like planets or ships ownership, but alas - that requires an index or ID and another table, which is essentially the same problem but fractured. It's a design thing, so I'm just cutting things and returning to making the game be a working game for the time being. The good news is that the data as is now fits.
  14. WELP OKAY...Time to cut some features and learn how to somehow offload... RGN$(9,19,2) (Would like it 9,19,4) SCTR$(9,9,4) To other parts of memory. I do not know how to do this, but willing to hear ideas. I haven't looked at manipulating the High Ram, but I suppose it's time to learn. Strings seem to be too heavy, and there's no way to define these as character arrrays, instead. A single character is 2 bytes, but a string is 3+? and that's a little mystifying because I'm reading different things, here. After cutting a few things, I'm back up and running but I don't know how I'm going to link up Planets and Civs or Manage Ships...
  15. Don't let "The Curse Of The Engineer" slow you down. I'd imagine the basic design of the game has your program's heavy lifting done in the Low RAM segment, and your heaviest Data can be stored in the Vera's VRAM banks. However, "The Heaviest Data" is yet to be clear. If you add graphics and sounds - you'll need to be changing banks a lot to handle how and when your data is present and being accessed/modified by the program, and that creates...well... A lot of potential for Speedrun Exploits and intentional (and unintentional!) memory corruption. XD Considering the basic design of the X16's memory map? I'd treat those banks like Actual Discs and the program as a Slow, impatient User. They want as much continuous game as possible without swapping. As many related or linked things should be on a Disk at a time, and going back and forth should be as complete as possible. This might mean that you really can just go at it and take up as much space as you want and then pare it down when you must. If anything, Just pad out data segments that you might need and then cut it. This is helped if you have your features prioritized and all plugged into your Big Three Things of Star Trader. If it doesn't immediately satisfy The Big Three? Put it on a shelf. There's a story I once heard from some developer of a game: the program was something like 2 megabytes over the memory limit, and the company was freaking out close to immanent release. He goes, deletes a few lines esoterically buried in the program, and everything was fine. He did it on purpose for that exact contingency. Hope this helps. I can't say I've personally messed with the system the way you are, but looking forward to hearing more. This sounds like Freelancer, and simulation games are very difficult and I definitely think not enough people are making good sims without getting forever lost while we all get old waiting for sim projects to deliver. XD
  • Create New...

Important Information

Please review our Terms of Use