PokéBASIC engine. A fan made engine for Pokemon fan games!
I've thought about that and decided to stick with real sprites. The backside adds to the experience and if I'm making one for every pokemon (that we add in) I might as well put everything into them.Ok update #1: I've begun making the base engine. I'm deciding to go with the pokemon red sprites because it fits with the 8 bit sprite sheet. I would like unique sprites but I'm bad at sprite making. So I might make the base engine with gen 1 sprites for the world and characters just with color. I would rather spend time with coding instead of sprite making so if you want to help with that, let me know. Walking one 16 pixel tile takes 32 frames. Is that the same as gen 1? I don't know. The sprites are set 2 times bigger with SPSCALE (SPRITE),2,2. this looks better on screen. I have no background set, because I have no custom background sprites. I might make placeholder sprites. They won't look too good lol The big issue right now is the pokemon. I have no easy way to have sprites for a lot of pokemon. A possibility would be to have pokemon sprites for battles set on background sheets, and print the pokemon like that, and if the pokemon is saved on a different sheet, then it loads a new sheet after printing the first and then prints it. This might work, as long as it doesn't overwrite the previous sprite. I haven't tested this yet. I will later tonight. Pokemon in gen 1 and 2 were made with what looks like 32 pixels by 32 pixels. That's 4 sprites. So it might only take 2 or 3 background sheets to fit say, 150 pokemon. Just an idea. Give me your thoughts.Maybe add an extra option, where you have to Pokemon facing eachother in a 2-dimensional manner? Two front sprites facing eachother can be an option as well as the traditional battle perspective.
Another update:
I'm working on the map loading and rendering. I'm making the program separate of the main game so I can only focus on the single feature. It used a custom save and the sbmap cannot be used for making parts of the map, so I will make a program for making maps. Shouldn't be too bad. It is being built for an open world style of game where it loads 120 by 120 tile chunks. It causes a quarter second of lag or so, because of the loading of new chunks, but it will be far and few in between. 60 tiles in between each chunk load.
Each chunk has 4 sections that load different chunks. Similar to diamond and pearl, when crossing a certain point, it will load the chunk that your headed to. It will at all times have 4 chunks loaded. Let's say your at the top left of the current chunk. It will load the chunk to the left, chunk above, and chunk to the north west. When crossing chunks, it will only change the layers. I don't think this will cause lag. But chances are I will have to reload every chunk into the new layers.
But other then that I dont know what to say. Give me your thoughts.
I might have to change the whole 120 by 120 chunks because the array is out of memory when I make it
DIM MAPDATA[11,11,121,121]Wich is what I started using for my test build for the map. I'll find a comprimise. I'm thinking after a certain set of chunks it loads a new set of chunks entirely, wich ruins the open world, but might work. I'll get back at it tomorow or later tonight.
I might have to change the whole 120 by 120 chunks because the array is out of memory when I make itA better way of making chunks is by having 'layers' of tiles:DIM MAPDATA[11,11,121,121]Wich is what I started using for my test build for the map. I'll find a comprimise. I'm thinking after a certain set of chunks it loads a new set of chunks entirely, wich ruins the open world, but might work. I'll get back at it tomorow or later tonight.
DIM MAP[64,64,8] C_WRAP = 4This saves memory space. The first two numbers are the dimensions of each chunk, and the third is the number of chunks. At the start, 4 chunks are loaded, and we'll have the player at the center. When the player has travelled to the right edge of the chunks, we have them wrap around to the left edge and swap the tiles to the next set of chunks. When they have travelled 4 full chunks to the right (determined by C_WRAP), we prevent them from moving any more. This way, the top half of the 4 chunks will take data from chunks 0 and 1, but the bottom half will be taken from the two chunks that start from a multiple of C_WRAP, which are numbers 4 and 5. This allows us to have chunks 2 and 3 represent the two chunks that come after 0 and 1 (when the player walks to the edge), making it easier to have the chunk index one dimensional, but displayed as a two dimensional map. Sorry if my explanation was very confusing, but I just came up with this right now, and I can't really make a demo to show you how it works, but trust me, it's more efficient and can help you implement chunks better.
I have some basic romhacking experience on Pokemon 3rd gen games, I can explain mechanics and give forth ideas for the engine. PM me if you require anything, I shall PM when I have an idea or query.What can you do? I'll be on later I won't respond for a while I'll be busyHoly crap this is a popular thread? Oof I can't quit it now. I need people to help out then! If you want to help out with the project then let me know!I am available.
Ah. Thanks for your input, plancake,but I found a good work around.
I'll have 64 by 64 tile chunks and have 10 chunks by 10 chunks. These will be called grids for now. Every time you get to the end of a grid, and cross it, it loads another grid with its own chunks. This will continue in directions where grids are programmed.
TO prevent making multiple arrays to use, I will instead load mapdata into the single array, overwriting the data from previous arrays. Hell, if I create an outer parimiter around a grid, or have 11 by 11 chunks, and the 11th chunk can be a dummy chunk to make the world continue seamlessly. Going into a dummy chunk loads the map data file for the grid that the dummy chunk is representing a chunk of. This can be easily and accurately made by, in the map creator program that I'm going to make, it stores the dummy chunks into their own arrays. Like DIM DUMMYCX [X,Y,WHATEVER,WHATNOT] AND THIS DUMMY CHUNK is loaded directly into the next grid as a regular chunk. And vise versa. Edge chunks next to dummy chunks become dummy chunks for the grid that the dummy chunk belongs to.
This may be overcomplicating it, but it both keeps the open world feel, and solves the memory issue of having oversised arrays that use up too much memory.
Thoughts? Sorry if it's confusing
Something I didn't think of when making my map system for SmileBasic, would be to load rows of tiles in, as needed, for a piece of a map, inbetween frames, so that by the time the player fully scrolls over to the area it's loaded, and you save on cpu and speed.
So you do a partial load of say one row of tiles (depending on the row size), and by the time the camera can see the first few rows loaded, the entire area is already loaded, it shouldn't create gameplay lag this way and should only take a short amount of frames.
Don't worry my man. I have fuze4 downloading right now. I might even be able to make it 3d in the future! So in any case, i am going to need more people using fuze4.Most people prefer SB to FB. If you prefer FUZE, you're kinda on the wrong site Also, there are a few SB 3D engines. the oldest, P3D was even ported to SB4 during beta testing