Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by JohnGill

  1. Hi all, I've realised that the majority of the game action takes place via the message window. Quiet Isle is leaning more towards text adventure, with strategy / resource management playing more of a supporting role. So I've pinched a few rows from the main hexes window to give me more space for the player's stats/progress/feedback etc. I've finalised the encumbrance mechanic for carrying resources. It's a hybrid weight/size system - your backpack fills up as you collect food / wood / stone. Larger things take more space and so you can't carry as much of it. So for example, carrying 1 unit of stone take up 16 "slots" of backpack space, whereas 1 unit of bread only takes up 4 slots, or 1 unit of seeds takes up 1 slot. The total number of slots allowed in the backpack is 255 (1 byte - how handy!) so the player has to make decisions as to how much of each kind of resource to carry around. I've also added a couple of new mechanics: - experience points : combat will be an element of the game, requiring the player to fight monsters to advance in levels in order to be able to complete the game. It'll be quite basic (health/attack/defence stats only) but I've not yet completely finalised how it will be implemented. I've allocated vram for 16x16 monster graphics and three x 8kb bank memory slots for monster descriptions which gives me space for 108 different types of monster! Sadly given my spectacular lack of animation skills the fights I'm pretty sure will have to be text described, taking place via the message window. - days elapsed : the game now keeps tabs on how many days you've spent in the game (in-game days, not real-life days!), and specific timed events will take place after a certain number of days no matter what the player has achieved, requiring them to get their move on and not just harvest wheat for weeks on end, this ain't Stardew Valley!!! That's all for now, here's how it's looking after the interface re-hash:
  2. Ooh ring bound manuals! My goodness the prospect of flipping through those pages of retro joy shouldn't elicit such eager anticipation but oh boy it does! Here's hoping Kevin and the team manages to get those bugs out of prototype board 2 soon!!
  3. Hi all, I'm using cbm prg studio to compile binary data files with a mixture of individual bytes and text to load into memory banks (see screenshot) When I'm using the following type: text 'This is a string of text.' by enclosing the string in apostrophes ' ' this compiles beautifully into screen codes in upper and lower case, - this is a very handy feature of prg studio, particularly for a heavily text orientated game like mine. My problem is I want to put an actual apostrophe into the text string, for example : text 'You don't know where you are.' But this then causes problems for the compiler - the first apostrophe after the n in "don't" confuses it - What it does is it deletes the first apostrophe entirely, reducing the string in length by one byte (which caused me some headaches before I spotted it!) Does anyone know how I can tell prg studio to include an actual apostrophe (screen code $2c) within the text? I could do this, but it is incredibly clumsy: text 'You don' byte $2c text 't know where you are.' any ideas? thanks John
  4. Hi all, another quick update. Got the rivers, tracks and bridges implemented now - the maps are beginning to look a lot more interesting! Also load and save maps routines up and running
  5. Hi all, Remarkably, I've managed to write an assembly routine that displays the value of a byte, in decimal, at a specified location on screen, and it works! (Got all my sec's and clc's the right way round and everything! I'm feeling very chuffed with myself and my over-inflated ego deems a hearty round of applause is in order ) I didn't google any examples, I wanted to have a bash at writing it myself from scratch as a learning exercise as much as anything. I know this is re-inventing the wheel and all that, but I wanted to write it specifically for the CX16 to be efficient as possible. It uses four bytes of zp memory (2 bytes for required x,y tile/cell position on screen, 1 byte for required colour attribute, and then the actual number to be written in decimal). It compiles down to only 74 bytes (excluding setting the vera stride, which is assumed to be 1 before calling the routine). Downside of this method is that it always displays leading zeroes. (eg, if the number is 26, it displays 026 etc) I presume this is a routine that all proper programmers have written hundreds of times in their sleep, is this the best way of doing it? It only has to display 0-255. ; vera stride needs to be set to 1 previously ; write the number to be displayed into display_byte ; pass the required x,y cursor position to the routine in decimal_x and decimal_y ; set colour to the attribute byte required for the number colour ; this example uses zp $20 - $23 but could be any free zp values display_byte = $20 decimal_x = $21 decimal_y = $22 colour = $23 lda decimal_y sta $9f21 ; set the vera y-cursor lda decimal_x asl a sta $9f20 ; set the vera x_cursor (has to be x *2 - two bytes per cell to allow for attrib. bytes) ldx #0 ; use x to count up the number of hundreds, tens and units lda display_byte sec hundreds_loop ; hundreds first sbc #100 bcc do_tens inx sta display_byte jmp hundreds_loop do_tens jsr display_digit ; display the hundreds digit (also reset x) tens_loop ; count up the tens sbc #10 bcc do_units inx sta display_byte jmp tens_loop do_units jsr display_digit ; display the tens digit (+ reset x) units_loop ; count up the units sbc #1 bcc finish inx sta display_byte jmp units_loop finish jsr display_digit ; display the units digit rts display_digit txa ; put the decimal column digit from x into acc clc adc #$30 ; $30 is the screen code for the number 0 sta $9f23 ; write out the number onto the screen lda colour sta $9f23 ; write out the attrib byte onto the screen ldx #0 ; reset x lda display_byte sec ; get ready for next column subtractions rts
  6. Hi all, I've spent that much time rummaging through documentation for vera trying to find how to set things up and which blasted $9f!*'@! did what, I thought I'd make myself a crib sheet with all the info on a single page (well, most of it!). I've attached a .png and a .pdf here for anyone to download and use if you want. I'm working exclusively in tile mode at the moment, so this crib sheet only covers that - I might do another one for bitmap mode when I start trying that. Hope it's useful to someone else! vera register info sheet.pdf
  7. Hi all, Drawing bug is fixed, and I've added the "only draw the hexes that have already been visited" thing. So now you start with a blank map with no idea where anything is until you start exploring! Next on my to-do list is to implement tracks, rivers and walls drawing routine. The entire map is 64 x 64 hexes - 4096 hexes in total. I've managed to encode rivers, tracks and walls into 1 byte per hex, 4kB for the whole map
  8. *facepalm* thanks so much. thought it would be something dumb!
  9. ... as usual! Hi all, I've got a piece of code that moves the "vera cursor" to the left four cells on screen: dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 8 decs, tile byte and attribute byte x4. This works and is fine and does exactly what I expect it to. However, I then thought I'd be clever (HA!) and make a tidier bit of code, like this: version 2: lda $9f20 clc sbc #8 sta $9f20 Except this doesn't work. When I substitute version 2 for version 1 into my program, it screws up the cursor positioning on screen and I can't for the life of me see what the difference is between the above two bits of code. How could they possibly give two different answers? Thanks In Advance! John
  10. Thanks. For my game in particular, I'm using a mixture of basic and assembly as a learning exercise to teach myself assembly. I'm using the CBM Prg Studio development environment which was designed for the C64/C128, but it works well enough for the majority of the time for the CX16. I'm putting my text into RAM banks. I create each bank from within CBM Prg as an assembly page and then compile them individually as a .prg binary to be loaded into the game as and when needed. CBM Prg is especially good at handling text in this way, as the CX16 uses identical PETSCII screencodes to the C64/128, so as long as I mark text as "text" type in the assembler, then the upper/lower case characters get transferred to binary with the correct petscii screencodes for the CX16, so I can just type exactly what I want to appear on screen into the assembler. If that makes sense?!?! I'm on a learning curve on this one too, and it took me AGES to get my head round why my mixed upper/lower case text wasn't transferring correctly. I've not written a word-wrap routine, I know how wide my text display window is, so I just manually wrap the text as I'm writing it in the assembler, screenshot below from CBM Prg studio, showing an assembly tab for one of the RAM banks:
  11. Hi all, One step forward, two steps back. It seems very much that This Is The Way for software development. Either that or I'm just inept I got the save / load bank feature working, and added a creation tool so I can make maps within the software itself rather than handcoding with a hex-editor (which would be UGH!) BUT, having started to draw the first map, a bug has manifested itself in the code that draws the layer 1 16x16 graphics over the hex backgrounds so now I've gotta go fix that before I can carry on. *Sigh* at least the map creation tool works! Onwards and upwards...
  12. Yep cracked it - thanks all! Now I can make a save / load game routine for my hexes game! Good spot @Ender on that "filename" positioning. My 6502 assembly skills are coming in hops and crawls!
  13. I think you've cracked it Ender, thanks - I do indeed call the subroutine from basic with a sys call, so I'll try moving the filename to the end of the code, I bet that fixes it (and correct the filename length) on my phone at the mo so will try it in the morning
  14. Rummaging through the latest user guide on github, I found this: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#load-into-vram - which I thought I'd try. But it doesn't seem to work (see screenshots). VLOAD still works fine in R38 so I can still load stuff into vram, but I'm a bit puzzled why the new LOAD format isn't working for me in r38 - shouldn't it be defaulting to "8"...?
  15. Hmm one step forward - I tried switching over the order that I call SETNAM and SETLFS so that SETNAM is called first, and that now makes the subroutine complete normally in r38 - it now RTSes back to basic properly which it didn't before. But there's no file written in the emulator directory. I'm running the emulator "manually" from its own folder, not from the emulator launcher within CBM Prg studio. I even did a search on my entire hard disk for "bankxx.prg" in case it was being written somewhere I wasn't expecting it - but nothing there. I tried switching over the a / y, still no file written. I tried removing the y as suggested by Greg, still no file written. I copied and pasted the exact same .prg file into my r37 folder and ran it using the r37 emulator, and bankxx.prg is written into the r37 directory fine - all 8Kb + 2 header bytes of it. I don't get it... there's obviously something else at play here since it's working fine for you and @Greg King - any ideas what I could check next?
  16. this is what SHOULD have been in the original post! It saves a block of normal low-memory (non-banked) onto the file system, same folder as where the emulator is run from. worked fine in r37, doesn't work in r38...
  17. Ugh, sorry, I've only just noticed the block of code I thought I'd copied and pasted in the past above has mysteriously disappeared. I'm on my phone at the mo, I'll update once I'm back in front of my pc.
  18. A much neater solution, thanks Greg!
  19. Hi all, I've got a bit of code that saves a specified block of memory to a file. It works fine in r37, but it doesn't work in r38, I'm guessing the implementation of the kernal save has been affected with the SD card management additions in r38. What do I need to change to get it working again in r38? Hoping someone can shed some light on this, thanks in advance!
  20. Hi all, I've been wading through the dullest of dull bits of coding in the ongoing saga of my first ever game dev. I've just finished getting the player's stat bar "blobs" to function correctly. The routine reads the appropriate byte from the player's stats stored in one of the memory banks (health, gold, fatigue etc...) and draws the correct number of blobs, in the correct colour, in the correct place on screen, including splitting over 2 rows if necessary, including quarter / half / 3-quarter blobs. I wrote a simple version of the mod (%) function to do the fractional blobs which worked first time (OH JOY OF JOY!). Then wasted about 2 hours bashing my head against the desk trying to fix a bug which boiled down to me putting "0" where I should have put "#0". (NO JOY! REALLY NO JOY!) Unfortunately the game looks no different to how it did a month ago, but now I can get on with some more creative aspects of the game! Oh, and I've now got a working title for the game - "THE MYSTERY OF THE QUIET ISLE" which kinda sums it well I think Onwards and upwards!
  21. Thanks, I made the notes in Corel draw, which is a graphics package I use in my day job so I'm very familiar with it. Use whatever you're familiar with! Good luck with getting your own game going
  22. Hi all, Been on family holidays/vacation last month so not much coding done recently. The terrain count now stands at 21 of the final 32 terrain types. To witness my legendary pixel graphic skills (ahem ahem) see below. The terrain types currently are: wild scrubs ; forest ; desert ; rocky outcroppings ; marsh lake ; cliffs ; high mountains ; lowland fells beach ; orchard ; cave ; meadow ; pasture lumber yard ; wheat field ; cleared ground ; ploughed field farmstead ; watermill; ocean I've still got a drawing glitch on the layer 1 terrain graphic overprints, down the right hand side of the hex window - I need to print only the left half the graphic if it's at the end of an odd numbered hex_y row. Finding an odd number in assembly is ABSURDLY easy: LDA hex_y AND #1 this leaves 1 in the accumulator if hex_y is odd, 0 if it's even. that's all for now!
  23. Great news! Thanks for the update. Will this build include a fix so that the banked area of memory $A000-$BFFF can be saved to a file?
  24. Hi all, I'm going to have to come up with a title for this project sooner rather than later.... Made good headway on coding up the different hex graphics on layer 1. I've done 8 different terrain types so far (sea, lake, beach, scrubs, meadow, pasture, orchard and cave) - there'll be 32 different types in the finished game. Pixel graphics is not one of my strong points, but hopefully it should be obvious which is which! I've finished the hex terrain text descriptions and written and debugged the scrolling routine that scrolls the message window as you move from tile to tile. It counts lines scrolled and if there's more than a window's worth of text to scroll all at once, it brings up a "Scroll..." prompt and waits for the user to press the enter key before continuing to scroll. The assembly for it runs so blinking fast, I had to write a delay subroutine that gets called inbetween each character being drawn so you can actually see the text scrolling, otherwise it looks like all the text just appears on the screen at the same time. (ignore the drawing glitch going on at the far left hand edge of the hex window, next thing on my list of things to fix!) Suddenly it's beginning to look more like an actual game now! ta ta for now
  • Create New...

Important Information

Please review our Terms of Use