Jump to content

JohnGill

Members
  • Content Count

    44
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by JohnGill

  1. 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!
  2. 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?
  3. 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
  4. Great job with the Vera Frank. Thanks for all your hard work getting this project its visuals (and some sounds!!)
  5. I'm sorely tempted Matt.. sadly I fear if I get stuck into this it'll come at the price of less work on my hex game. If only I had more time! Keep us posted!
  6. Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  7. Thanks Matt - great to know it's not just me being a doofus again!!!
  8. Hi all, I'm afraid it's the assembled blunderer here again, I've written a routine that's supposed to save a specified ram bank to disk, in this case, ram bank 2. The routine compiles and runs fine, and outputs a file of the correct size (8194 bytes: 2 header bytes + 8192 data bytes), the header bytes even show the correct $00 $0A. Hurrah thinks I - my assembly skills are finally improving. But apparently not - the data in the written file is just some random junk, not what was in memory at $A000-$BFFF. It should be $09 and $06 alternating, as shown in the third screenshot. *Sigh* I'm hoping a kind person can spot a stupid mistake in my code.... please and thank you.
  9. Right, real progress being made now - finally got the blasted text thing working! I've edited the default char set 2 and remapped my hex-building characters so I can have rounded corners. Very pleased with how it's looking now. Slightly changed the main screen layout too since I had to re-do it with the updated character set. Added some more commands and moved all the resources / carried items into a 'backpack' that you can open to look inside, and it'll come up on a separate window. Thanks so much everyone - what started off as a simple little endian mistake on my part turned into a bit of a deep dive into a rabbit hole of petscii and screencode. I owe you all a drink or 5!
  10. Ok, latest experiments... I wrote a routine to convert petscii to screen code, using that chart I linked to above (see first screenshot below) and it works! Well.... almost... kinda... It does display the correct glyphs for the text, but they're all reversed out (see second screenshot) "Aha!" Thinks I, "the petscii character set from 129-255 is just a duplicate of 0-128 but reversed out, so all I need to do is subtract 128 ($80) from the final value and it should work"... well... no, tried it and um... see third screenshot. I've checked the attribute bytes and they're correctly set for black background+yellow foreground ($07), and the space characters are showing as spaces rather than yellow boxes so these characters really are reversed out. Getting so close to fixing this I can almost taste it!!!
  11. Hi Greg, OK, I tried unchecking the detect character set box and re-compiled the bank1 with apostrophes instead of quotation marks and just got the same blue screen clearing as above. I also tried switching character set from "upper case only" to "upper and lower case", and same result. It was worth a try. CBM definitely being too clever for its own boots. *EDIT* Actually, it was the basic bit of the program that was causing the problem - trying to PRINT characters to the screen that were screencodes. Using the apostrophes actually cured the assembly printing but the basic bit blanked the screen so I couldn't tell until after I'd deleted the basic bit!! So HUGE THANKS for that tip! FIXED! The odd couple of capital characters I've redefined myself, moving them around will be easy now I've got this bit sorted.
  12. So I switched the " to ' and recompiled bank1.prg, and sure enough, the text bytes are encoded completely differently, so CBM PRG Studio is doing something clever. But not clever enough it would seem - now when I run it, it does a screen clear, and I'm getting different gobbledigook so the new values are still not correct. I'm going to go back to quotation marks around the text rather than apostrophes, I know then that CBM PRG Studio outputs PETSCII values into the bytes for upper and lower case characters. All I need to do then is, before writing each character to the screen, send it to a conversion routine that checks the PETSCII value held in the byte, and converts it to a screencode. I found a table here : https://sta.c64.org/cbm64pettoscr.html so it seems straightforward enough. On a very steep learning curve here, but it feels good to be getting to the bottom of this ASCII/PETSCII/screencode weirdness! Thanks Stephen and Greg. I'll report back!
  13. Thank you very much! Yes that sounds very probable. Something concrete for me to work on.
  14. I've not done that deliberately - I'm the only one writing this so the screw ups are all mine it is definitely something to do with how the character sets are being handled, so I'm going to dig a little deeper down that tunnel. Perhaps the kernel calls from print do something clever to make the correct characters appear on screen that my hard-coded vera calls ain't doing.
  15. pff. exactly the same. ah well. although here's a weird thing - I quit out of the program, and typed in the line 'In a wild and rough scrubland' with the shift key held down - and I got exactly the same string of characters as the assembly is displaying (apart from the capital I which didn't appear reversed out). Question is, why is the text displaying correctly when called with print chr$() in basic? Curiouser and curiouser....
  16. if I'm switching to use vera port 1, I'd also need to change line 120 (sta vera_data0) also to sta vera_data1. I've set up all the variables at the top of the assembly to the appropriate register values to I don't have to keep remembering them I can't see how it'll affect it, but I'll try anything at this stage I'll give it a go...
  17. Hi Stephen, thanks for the reply. I did sign up with github a couple of years ago but couldn't make any sense of how to use it. You seem to be confusing me with an actual programmer . In the screenshots below, I've shown how I've coded the bank 1 data in my assembler - this compiles to a prg and loads up fine into the emulator. I've also shown the basic program where it calls the 'print' assembly routine (sys $2a90) and then the assembly code section where it writes the ram bank section onto the screen. (startHi should really be called startLo - I got my endians muddled up - as pointed out by togster510 above! I switched them round but didn't change the variable names). jsr scroll is a subroutine I've written already and tested, that works perfectly - just moves all the message window up one line, leaving the bottom line blank for the next line of text to be written up. I've also attached a screen shot of it running to show how the assembly displays the message from the bank (yellow section at the bottom of the message window), and then at the top of the window, I've put some basic code in that loads exactly the same bit of memory and writes up the first line perfectly. The assembly is definitely reading the right bit of memory, the spaces in the top row line up perfectly with the spaces in the basic printed line. It seems to be something to do with how print chr$() interprets the character set but I can't work it out. Any ideas?
  18. I'm using the 'text' type in my assembler and compiling the ram bank as a .prg . It's strange, because when I print chr$(peek($A134)) from basic, the characters come up on screen correctly. I'm obviously doing something dumb with the assembly but I don't know what yet...
  19. it's supposed to say : the spaces are all in the correct places, and the capital letters are all there (I, T and F), just reversed out. I've replaced some of the upper-case characters to make the hex-construction graphics, and the resource blobs as well. I'm going to re-organise my character set map but the untampered-with- lower case characters should still display correctly shouldn't they? I'm still a bit of a noob at petscii and how the character sets are handled so it could just be that I'm being a bit dim. *edit - don't know what happened to the text I copied and pasted above - it should have said "In a wild and rough scrubland. Thick grasses and heathers make the going slow, and gorse bushes pick at your clothes. From unseen heights, the cries of distant birds catch on the wind from time to time.%"
  20. curiouser and curiouser.... I've switched startLo and startHi around into proper little endian order, and now I get this (see attachment). It seems to be the correct text, but all the lower case characters have turned into graphics and the upper case characters have been reversed out. And now the BASIC bit that prints the first line of the message doesn't print anything at all! coding in assembly for me just feels like one step forward two steps back every time!
  21. ah! that makes perfect sense. yep, thought it might be some noobish error like that. Many thanks, I'll switch them up and see what happens... (!!!)
  22. Hi all, I'm working away furiously at writing a routine in assembly that will scroll text within a window on screen for my hexes adventure game, loading text from a memory bank and adding it at the bottom line by line. This is really stretching my assembly skills but I'm enjoying the challenge. I've got my head round using both vera's data0 and data1 to read and write the screen to shuffle up the whole window a line at a time, but I've come across a blip that I can't get my head round, and I'm wondering if someone can please point me in the right direction: I'm copying a string of characters from somewhere in the ram bank space ($A000 upwards), which is referenced by two ZP vars that I've assigned to variables thus: startHi=$14 startLo=$15 I've written the maths routines to calculate the start position of the required string, which sets startHi to say, $A1, and startLo to say, $34. The maths routines I've tested and know are working, they give the correct values in startHi and startLo for the base position of the text within the ram bank. My problem seems to be actually copying those bytes to the screen. I'm feeling exceptionally clever for working out how to use the y register in indirect indexed addressing mode to step through the memory thus: loop: lda (startHi),y ..... do stuff But it ain't working (yet ). If I've understood things correctly, this is supposed to look at the byte at memory address startHi ($14 for me) *and* the byte at memory address startHi+1 ($15, startLo) and use that as a two-byte base address, and then add on the value of y. Is that right? When I run the routine, it just writes a ton of "@" to the screen. I've set the break point at the start of the loop with the debugger monitor thing (very useful), and it steps through y from $00 > $FF fine, and sure enough, its just loading zeros into the accumulator at the lda (startHi), y line every time. I can see the ZP vars in the debugger, and $14 and $15 are indeed pointing to $A1 and $34 (or whatever), but I don't understand the debugger well enough to work out if I can look at the actual $A134 while I'm stepping through the assembly. When I print chr$(peek($A134... $A135... $A136 etc)) from basic, then it shows that the characters are indeed present in the ram bank page (see below). So why does my assembly just find zeros? Any tips very gratefully received!!! thanks
  23. I'm using a combination of basic and assembly. Taking the CX16 as an opportunity to learn and write games in assembly. I'm using the CBM PRG Studio package - It's designed for Vic20/C64/C128 but it still works with the CM16 emulator. I can write basic and assembly in a nicely laid out IDE, and it compiles assembly, and combines it with basic to make a single PRG you can load directly on the emulator. Although from the conversations I've had with *proper* programmers on here (I don't consider myself proper!), this isn't ideal, and I should really move onto a better compiler!
  24. Thanks for this Andy, I'll investigate...
  25. Hi all, I'm having a problem with loading completely full ram banks from disk in BASIC. I've got a file that's 8194 bytes (2 location header bytes + 8192 data bytes) and when I try and load it up with: POKE $9F61,1: load"bank1.prg",8,1,$a000 then it just loads memory with a bank full of zeros, seemingly ignoring the file completely. If I trim 2 bytes off the "bank1.prg" file size, to exactly 8192 bytes (2 location header bytes +8190 data bytes) then it loads into the bank fine, leaving two empty bytes at the end of the bank. Am I doing something wrong, or is this an emulator "feature" that needs addressing? thanks
×
×
  • Create New...

Important Information

Please review our Terms of Use