Link6415 Posted November 8, 2015 Author Share Posted November 8, 2015 Hmm... roguelikes take a lot of memory. I need to find 2016 free bytes for my 32 sprites. Hey, that rhymes! If necessary, I can make each dungeon level smaller... What do you think? Quote Link to comment Share on other sites More sharing options...
carlsson Posted November 8, 2015 Share Posted November 8, 2015 How does your memory map look like right now? If you don't need to modify the sprites, I suppose they can go into the 16K block $E000 - $FFFF where your custom characters (previously bitmap) also would go. Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 9, 2015 Author Share Posted November 9, 2015 (edited) That will work. Chars are at $C800 Sprites are at $E000 Level maps are at $9000 I might have to make the maps smaller to make room for BASIC. I haven't needed machine language yet, although I may need it soon if I want music. The smooth scrolling uses PRINTs (not trying to brag, but that was a great idea). I need to put in the sprites before I can show it off, you'll see why then. More soon! Edited November 9, 2015 by Link6415 Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 14, 2015 Author Share Posted November 14, 2015 (edited) I threw out the rock tiles in favor of bricks. Here's a real mockup: Edited November 14, 2015 by Link6415 1 Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 14, 2015 Author Share Posted November 14, 2015 I am away from home now, and I can't look at my notes and books that have information I need to get all the sprites working. I'll be home tommorow and I can do it then. For now, I do have a few sprites (you can see the rogue in the mockup.) Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 17, 2015 Author Share Posted November 17, 2015 still working on monster sprites. what do you think of the new mockup (this shows what the screen will look like; how it will show up, where stats are displayed, ect.) Quote Link to comment Share on other sites More sharing options...
carlsson Posted November 17, 2015 Share Posted November 17, 2015 Much smaller window than I had thought. Also, what about the smooth scrolling? If you would have a maze area that is as wide as the screen, you could use raster timing to scroll that part of the screen while leaving the stats and other display at the top/bottom static. A small window would require other techniques, probably bitmap redrawing to get it to scroll. At least I don't know any easy way to solve that, definitely TMR is more talented in that respect. Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 18, 2015 Author Share Posted November 18, 2015 Thanks for the feedback. I have been feeling a bit down and discouraged lately, and it helps to see people giving their thoughts. The window is small because it is made of sprites. If I wanted a bigger window, I would've needed more sprites and there would be no room for other objects (sprites). The windows will only pop up if a certain key is pressed, or if combat is initiated. I PRINT the screen like this: I have all the data for the maps in memory as CHR$ values, not POKE values. I set a value that I call the cursor (represented by the variable "L" currently). I read 12 values across, 12 times, adding 64 each time, since the maps are 64*64 bytes large. So my cursor is "L". Lets say "L" equals 36864. This means the top left character in the window is the top left character in the map, 36864 is the memory location where the map data begins. ($9000 in hex.) There As for the scrolling, here's how it works. The orange border is made of 4 multicolor sprites. They are actually black and orange, but you can't tell because of the black background. They are enlarged. There is enough room (4 pixels when small, but 8 when large) on each sprite to cover 1 8*8 pixel area (the size of a character). When I want to scroll left, I PRINT all the tiles (characters) behind the right border. They are completely covered because of the black on the sprites. Then, I scroll using the scrolling register. Next I set the position of the cursor to 1 tile left of where it was. Finally, I redraw the screen. This may sound complicated, so I might make a video to explain it better (I talk better than I type if you know what I mean.) Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 18, 2015 Author Share Posted November 18, 2015 (edited) *deleted* Edited November 18, 2015 by Link6415 Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 18, 2015 Author Share Posted November 18, 2015 Okay, there wasn't enough room for my HUGE post, so I saved it as a PDF. I was feeling a bit blah, but typing out what I've been working on really helped (for some reason.) Enjoy! Thanks for the feedback.pdf Quote Link to comment Share on other sites More sharing options...
carlsson Posted November 19, 2015 Share Posted November 19, 2015 I'm not sure I follow the scrolling part, but great if you get it to work as intended. By the way, while it probably is far slower than unrolled adds as you do it, you are aware that you could build the strings with loops? 105 S1$="":FOR X=1 TO 12:S1$=S1$+CHR$(PEEK(L+X)):NEXT Actually I think there is a SYS inside BASIC ROM that you can use to create a string out of data stored at a given memory location, given that it is zero terminated. It might be a bit cumbersome to use though, and I can't think of a more clever way to generate the strings from BASIC commands than how you currently do it. Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 19, 2015 Author Share Posted November 19, 2015 Yeah, I did try the loop and it was too slow. Quote Link to comment Share on other sites More sharing options...
stirring Posted November 21, 2015 Share Posted November 21, 2015 Like the mockup Link. It has a sort of Temple of Apshai feel to it but with better graphics. Keep up the good work! Quote Link to comment Share on other sites More sharing options...
Link6415 Posted November 21, 2015 Author Share Posted November 21, 2015 That's kind of what it's turning into. I want to incorporate a story, and make it kind of like Temple of Apshai meets Ultima meets Return of Hercules. It's coming along. Quote Link to comment Share on other sites More sharing options...
Link6415 Posted December 11, 2015 Author Share Posted December 11, 2015 Hi guys. A lot of progress has been made lately. I've been having a lot of fun working on this project so far . BTW the graphics style has changed, I'm now using MC mode. A question about sprites. Screen mem starts at 49152 ($C000), chars are at 51200 ($C800). Where do sprite pointers start? I have misplaced my reference guide (I'll probably need to get a new one actually ) Quote Link to comment Share on other sites More sharing options...
stirring Posted December 11, 2015 Share Posted December 11, 2015 They are the last 8 bytes of the video matrix (the 1000 byte Screen color ram area). The default is at $7f8-$7fff if your screen color ram starts at $400. If you set your screen color ram to $c000, then they should be located at $C3f8 - $C3ff I believe. The reason they put them there is because the screen ram always takes up only 1000 bytes, instead of a full 1k (1024). So basically there is 24 bytes extra free at the end of screen ram to use. Well if you are using sprite pointers, then you really only have 16 free bytes there, buy hey, every free byte counts in a C64 game! Good luck! Quote Link to comment Share on other sites More sharing options...
Link6415 Posted December 11, 2015 Author Share Posted December 11, 2015 Hmmm... Are there any other changes I need to make to the sprite building program? Any other numbers need changed? The program just generates 3 of the 8 sprites, and they are all solid black squares. Where do you suggest I put the sprites (in memory) Quote Link to comment Share on other sites More sharing options...
TMR Posted December 12, 2015 Share Posted December 12, 2015 Are there any other changes I need to make to the sprite building program? Any other numbers need changed? The program just generates 3 of the 8 sprites, and they are all solid black squares. Where do you suggest I put the sprites (in memory) The VIC-II can only "see" sprite data in the same 16K video bank that the characters and screen are in so, if the space from $e000 onwards is free it'd probably be the best spot.load them into that; you can put the data under the I/O space at $d000 onwards but loading it into there from BASIC without a decent fastload cartridge will be a problem. The values in those data pointers are multiplied by 64 and added to the start of the video bank in memory, so in this case that's 49152+(pointer*64) - a value of zero will obviously have the VIC-II looking at 49152 (or $c000), a value of 1 means at 49216 (or $c040) and so on with 128 pointing at 57344 ($e000). Quote Link to comment Share on other sites More sharing options...
stirring Posted December 12, 2015 Share Posted December 12, 2015 Have you defined a game memory map? If not, it will help if you first define your games memory map, where you will place your games code and game data given a particular memory setup. Here is an example of what a memory map looks like, https://www.c64-wiki.com/images/thumb/5/51/Memory_Map.png/500px-Memory_Map.png Section out your memory map and label each area so you can easily look at it and understand what is placed there. Label all free ram memory locations as well as where your actual game code and data will be placed. This should become something you can be proud of, hang on your wall and refer to many times throughout your development. Also creating a visual memory map will really help you figure out how the C64 works and allow you to be creative with memory usage. I have always created my memory maps the old school way, simply drawing them using ACSIII text boxes. This makes it very easy to modify them and make changes by simply copying and pasting things around, instead of requiring some fancy graphical tool. Just make such you are using a uniform text font if you want to do it this way or you will have problems aligning the ASCII boxes. Another thing about defining memory maps using ASCII is that they can be easily embedded inside source code, and I am always a fan of documentation that gets embedded along with source. Quote Link to comment Share on other sites More sharing options...
Link6415 Posted December 13, 2015 Author Share Posted December 13, 2015 Yes I have a memory map. Screen starts at 49152, sprites start at 57344, maps start at $9000 (I forget what that is in decimal) Quote Link to comment Share on other sites More sharing options...
Link6415 Posted December 19, 2015 Author Share Posted December 19, 2015 Lots of progress latley! Here's a quick screenshot Happy Holidays! 1 Quote Link to comment Share on other sites More sharing options...
Link6415 Posted January 20, 2016 Author Share Posted January 20, 2016 This project has been degenerating. My latest screenshot is a great example of me trying to push a few graphical effects even if it means sacrificing gameplay, which is basically all I've been doing. We need to get things back on track. I don't have anything else for now, but it looks like I need to get raster interrupts figured out. How does one go about "interrupting rasters" anyway? I may start a whole new thread soon, so keep your eyes peeled. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 20, 2016 Share Posted January 20, 2016 Unless anyone else chimes in, I can post a simple example of setting up a stable raster interrupt later on. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 20, 2016 Share Posted January 20, 2016 This code example should help you along the way. If you only need one occurence of the raster interrupt, of course you omit the raster2 and always jump to $ea31 at the end. sei lda #<raster ; set up raster interrupt sta $0314 lda #>raster sta $0315 lda #$7f ; disable timer sta $dc0d lda #$31 ; raster line where the interrupt should fire sta $d012 lda $d011 and #$7f sta $d011 lda #$01 sta $d01a ; mask raster IRQ sta $d019 ; set raster IRQ ; any other setup you want to do before the raster interrupt goes ; live.. but you could probably do most of that before "sei" anyway cli ; here goes rest of your main program, whether it is a busy loop waiting ; for the raster interrupt to set a flag or just running as usual ; ... subroutines and stuff raster: lda #$01 sta $d019 ; acknowledge raster interrupt lda #$a8 ; raster line where next interrupt should trigger sta $d012 ; add anything you want to happen at this raster line, i.e. change ; video mode in one way or another - not too much since time is tight lda #<raster2 sta $0314 lda #>raster2 sta $0315 jmp $ea81 ; short raster service routine raster2: lda #$01 sta $d019 ; add things you want to happen here (later or even off-screen depending ; on which line you set the second raster interrupt to trigger) ; add e.g. calls to a music player or whatever you have, depending on how ; you set up the raster you might have a bit more time here lda #<raster sta $0314 lda #>raster sta $0315 jmp $ea31 ; main (longer) raster service routine, which you ; only need to trigger once per frame or so Quote Link to comment Share on other sites More sharing options...
Link6415 Posted April 1, 2016 Author Share Posted April 1, 2016 Hello. This project is not dead, not even close! I've been working harder than ever, but I haven't posted anything for a while. A quick update: the graphics have been tweaked, and I plan on changing the screen layout. Also, I am almost done with the random level generator, and getting ready to work on encounters and combat. I have been getting a lot of inspiration from Atari 2600 games, I want the game to be simple, but fun, and interesting. The graphics are also supposed to be simple and not bad (as in poorly drawn.) I will be trying to post more often, but that's all for now. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.