Tue Mar 22, 2016 9:44 am
I did indeed use a different one, after removing a minor glitch in my sd library I tested one that shipped with the gamebuino (IDK where my second one is, i just noticed o.O) and I didn't notice a speed difference, so yay!superfreaky wrote:Also, added to the demo for tilemap loading now dynamic flashing of sound data off of the sd card (damn, that is so fast, it's done in the blink of the eye)
Are you using the sd card that came with your Gamebuino? Or are you using a larger size, faster one?
superfreaky wrote:As for the black/white idea, it's not original [https://games.yahoo.com/game/shift-flash.html] but it's been floating around in my head for a while. I was inspired by the fact that black and white are the only colors available anyway, why not make a game utilizing that concept? Also, give me your honest opinion of the storyline. I can always start with a blank slate, new original ideas, but I thought I would start with a rather generic RPG story.
I thought of maybe a private repo and not release the source until the game is done? What do you think? For a private repo I'd use bitbucket as it allows private repos for free, unlike githubdeeph wrote:Can you upload your code ? Or we should maybe make a repo.
Tue Mar 22, 2016 5:00 pm
Sorunome wrote:I thought another way to save PROGMEM would be to maybe have a 256-byte buffer (8 * 32) in RAM which can hold 32 sprites, so that along with each tilemap the sprites are stored, so that on the SD card you will have [<tilemap-data><sprite-data>]. While this would allow for many unique sprites it would make the tilemap datafile on the sd card large rather quickly.
Sorunome wrote:Also, how to store what is walkable? Should that use the same 8x8 pixel grid or something finder, like 4x4?
Sorunome wrote:What about enemies / interactable objects?
Tue Mar 22, 2016 5:32 pm
Alright, github then?deeph wrote:I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.
Concerning the repo, I don't think it needs to be private.
I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads. Did anyone benchmark the read speed already? If not I can do it ^.^deeph wrote:Sorunome wrote:I thought another way to save PROGMEM would be to maybe have a 256-byte buffer (8 * 32) in RAM which can hold 32 sprites, so that along with each tilemap the sprites are stored, so that on the SD card you will have [<tilemap-data><sprite-data>]. While this would allow for many unique sprites it would make the tilemap datafile on the sd card large rather quickly.
Yes we could put multiple tilesets on the SD card, separatly from maps data, and load them on the SRAM when needed. We just have to attribuate an ID to the tileset that will be indicated with maps data.
Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or somethingdeeph wrote:Sorunome wrote:Also, how to store what is walkable? Should that use the same 8x8 pixel grid or something finder, like 4x4?
The easiest solution is to sort the walkable tiles from the non-walkable ones, like I did with this tilemapper. That way all we have to do is to check which tile is under the player's sprite, and if its number is above a certain one, then it is either walkable or not.
So what kind of different objects would we need? I can think of:deeph wrote:Sorunome wrote:What about enemies / interactable objects?
I think that we need to separate enemies handling from every other "events" handling : those which triggers when the player walks on certain coordinates (warps, "cinematics"), and those that are "interactive" (triggered by the player, typically facing something and pushing the A key).
It shouldn't be too hard to code, that's what I do with my current project. I'll show you the code when I got time to clean it up a little bit.
Tue Mar 22, 2016 6:05 pm
Sorunome wrote:I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads.
Sorunome wrote:Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or something
Sorunome wrote:So what kind of different objects would we need? I can think of:
enemies
NPCs
droppable/collectable items, switches
Tue Mar 22, 2016 6:55 pm
Made a repo here!deeph wrote:Ok for github (I don't remember if I have an account yet, though).
It would allow for way more flexibility, with only set 32-sprites-maps using unique sprites is next to impossible while dynamic loading still works well.deeph wrote:Sorunome wrote:I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads.
Mmh why not but it seems to be a little too complicated, to me multiple tilesets of 32 tiles are enough to make maps with different environments (indoor/outdoor etc..). We should start making so mock up first. If anyone else has 8*8 monochrome sprites that we could use for an A-RPG, feel free to share
I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.deeph wrote:Sorunome wrote:Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or something
Yes but again I don't think we need too complicated things like one-way tiles for a such a "basic" game.
deeph wrote:Sorunome wrote:So what kind of different objects would we need? I can think of:
enemies
NPCs
droppable/collectable items, switches
Enemies are not technically objects, because we'll have to handle their AI appart from the player. I think that all the other things are triggered by the player (even the objects that falls after an enemy death), and so are part of one of the two categories of events I cited.
Tue Mar 22, 2016 7:43 pm
Sorunome wrote:I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.
Actually, I just got an idea!
If we use 32-sprites spritesheets that will only be 5 bit, leaving the upper three bit for additional data for the tile, maybe have those upper three bits encode how the tile can be walked on? Or maybe use those upper three bits for some other flags, such as if something is supposed to happen when you step on it etc. and have a 32-bye buffer for the sprite walk-data elsewhere?
Sorunome wrote:Oh, sorry, I meant programaticall objects, objects when talking about OOP (Object-oriented programming) In that sense enemies are clearly objects
Tue Mar 22, 2016 8:37 pm
deeph wrote:I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.
Tue Mar 22, 2016 8:58 pm
Done!deeph wrote:Can you add me as a contributor ? I've created a new account : https://github.com/deeph-z80
I think it would allow for quite more awesome map designdeeph wrote:Sorunome wrote:I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.
Actually, I just got an idea!
If we use 32-sprites spritesheets that will only be 5 bit, leaving the upper three bit for additional data for the tile, maybe have those upper three bits encode how the tile can be walked on? Or maybe use those upper three bits for some other flags, such as if something is supposed to happen when you step on it etc. and have a 32-bye buffer for the sprite walk-data elsewhere?
Well we could do that too, it's just a little more complicated.
deeph wrote:Sorunome wrote:Oh, sorry, I meant programaticall objects, objects when talking about OOP (Object-oriented programming) In that sense enemies are clearly objects
My bad, I'm just not really used of OOP
I generally prefer using arrays for that kind of stuff, which I think is a concept more close to what the processor understand (so translated more optimally ?).
superfreaky wrote:deeph wrote:I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.
I'm thinking I should put the background story in the .INF file to save space (I haven't written it out yet but I know it's gonna be kind of big) and then just put little details at trigger points in the world. (This is a warp portal. Walk through it to access a parallel world!( said when you approach the first one)). Also, some brief text when major plot events happen, like when the sword gets found.
Tue Mar 22, 2016 9:13 pm
Tue Mar 22, 2016 9:16 pm
What's the point of that if all the data is read from the sd card anyways, that wouldn't add any overhead?
Also, after benchmarking the read speed it seems like we can safely assume at least 140 KB/s which is more than enough for loading data on every screen transition. More detailed benchmarks here.