So I started to make my Scary Forest program more Roguelike... and the first thing I did was implement a "fog of war" on the map.
It's a great idea: don't draw the map! Saves time! Only draw new bits when you get within, say, 4 moves. And then you can "see" monsters... and they can see you... and start lumbering towards you. I mean this is a win-win, right?
So I'll tell you: it DOES improve the feel of the game... a LOT. It adds some suspense. It adds an exploration element to the game. So there's emergent gameplay that I didn't realize was there. Once I add treasure, it'll be a whole new ball game.
...BUT...
...What I've found is that even drawing a 9 x 9 map from a 2D array, then handling player and monster movement, is too slow. Yeah, even with the Commander X16, it's too slow.
I optimized. I went memory-lazy and use an array of floats instead of ints. I got rid of newline printing and went all cursor controls. Up, down, left, right. It helps. But... it's still slow. It turns out that adding a line of logic here and there really add up fast... and this is just PETSCII!
So I'm fishing for suggestions. I've started asking myself what assembly language I can write to get the most speedup for the least amount of pain. Maybe the map drawing routine: fairly straightforward, no funny checking of data and switching around, so not a big chunk of code. I guess I'd POKE the map into a bank, and the ML would use ZP indirect indexing to find the right data, do a PLOT, and render the PETSCII. Next square. Do it from x-4 to x+4, y-4 to y+4. Maybe?
Or maybe I should use sprites for the player and monsters? They would sit "on top" of the map, so I wouldn't be drawing over it; surely that might help?
Question
rje
So I started to make my Scary Forest program more Roguelike... and the first thing I did was implement a "fog of war" on the map.
It's a great idea: don't draw the map! Saves time! Only draw new bits when you get within, say, 4 moves. And then you can "see" monsters... and they can see you... and start lumbering towards you. I mean this is a win-win, right?
So I'll tell you: it DOES improve the feel of the game... a LOT. It adds some suspense. It adds an exploration element to the game. So there's emergent gameplay that I didn't realize was there. Once I add treasure, it'll be a whole new ball game.
...BUT...
...What I've found is that even drawing a 9 x 9 map from a 2D array, then handling player and monster movement, is too slow. Yeah, even with the Commander X16, it's too slow.
I optimized. I went memory-lazy and use an array of floats instead of ints. I got rid of newline printing and went all cursor controls. Up, down, left, right. It helps. But... it's still slow. It turns out that adding a line of logic here and there really add up fast... and this is just PETSCII!
So I'm fishing for suggestions. I've started asking myself what assembly language I can write to get the most speedup for the least amount of pain. Maybe the map drawing routine: fairly straightforward, no funny checking of data and switching around, so not a big chunk of code. I guess I'd POKE the map into a bank, and the ML would use ZP indirect indexing to find the right data, do a PLOT, and render the PETSCII. Next square. Do it from x-4 to x+4, y-4 to y+4. Maybe?
Or maybe I should use sprites for the player and monsters? They would sit "on top" of the map, so I wouldn't be drawing over it; surely that might help?
Anyone got better ideas?
Link to comment
Share on other sites
21 answers to this question
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.