Jump to content

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Link6415

Share this post


Link to post
Share on other sites

I threw out the rock tiles in favor of bricks.

 

Here's a real mockup:

post-43309-0-92543500-1447540972_thumb.png

Edited by Link6415
  • Like 1

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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.)

 

 

 

post-43309-0-12797200-1447725363_thumb.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.) ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hi guys.

 

A lot of progress has been made lately. I've been having a lot of fun working on this project so far :D .

 

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 :( )

 

:D

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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)

 

:?

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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? :P

 

I may start a whole new thread soon, so keep your eyes peeled.

Share this post


Link to post
Share on other sites

Unless anyone else chimes in, I can post a simple example of setting up a stable raster interrupt later on.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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. :)

post-43309-0-45709800-1459477118_thumb.jpg

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...