Graphic layers?
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Graphic layers?
technically if you went totally insane you could do it with loves vector support
- Jasoco
- Inner party member
- Posts: 3726
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Graphic layers?
I don't know all the math and sines and cosines and stuff to even begin to pull that off. I couldn't even create a Wolfenstein style game, and that's the simplest "3D" you can have!
If there was like a built-in way to define a "world3d" with a certain size length, width and height. Then create objects inside the world at x, y and z locations with x, y and z scale sizes. From simple blocks to spheres to user created and defined polygonal objects that could be stored in an open standard of points and lines with the ability to set different sides of the polygon to a specific color or even an image beforehand.
then of course in the Update function you'd change the polygon shape's x, y, z or scaling or whatever as well as the camera's location and when the Draw function is called again you would run through all the polygons in the world and draw them. The program would be smart enough to draw them in the order they are located based on where the camera is.
The 3D could be used for something simple like a 2.5D sidescroller or a pinball game, or something more complex like a Starfox or Mario 64 type shooter or platformer. The world would have the same collision detection, gravity, physics as normal 2D worlds.
love.physics.newBlock3d(x,y,z,xs,ys,zs)
love.physics.newSphere3d(x,y,z,radius)
love.physics.loadPolygon("file.pol")
Stuff like that. It's simpler than I made it look.
If there was like a built-in way to define a "world3d" with a certain size length, width and height. Then create objects inside the world at x, y and z locations with x, y and z scale sizes. From simple blocks to spheres to user created and defined polygonal objects that could be stored in an open standard of points and lines with the ability to set different sides of the polygon to a specific color or even an image beforehand.
then of course in the Update function you'd change the polygon shape's x, y, z or scaling or whatever as well as the camera's location and when the Draw function is called again you would run through all the polygons in the world and draw them. The program would be smart enough to draw them in the order they are located based on where the camera is.
The 3D could be used for something simple like a 2.5D sidescroller or a pinball game, or something more complex like a Starfox or Mario 64 type shooter or platformer. The world would have the same collision detection, gravity, physics as normal 2D worlds.
love.physics.newBlock3d(x,y,z,xs,ys,zs)
love.physics.newSphere3d(x,y,z,radius)
love.physics.loadPolygon("file.pol")
Stuff like that. It's simpler than I made it look.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Graphic layers?
This subject has come up before and the answer will be and always has been "the goal is to create an easy-to-use 2D engine", anyway, if you really want 3d you may want to check out gLöve/Löve3D which is floating around in projects and demos. (link on the front page of the wiki)
Re: Graphic layers?
What I meant was, people like to make their maps in tables as apart of the actual lua file, I thought that's what you had meant. The grid based approach I should've said to be usable only in an editor and not in the actual script files, like, dynamically rendering them based off a grid stored in a table would be a bad approach, mostly because it would be alot of calls to love.graphics.* commands. (although I hear the LOVE team are coming up with a new way to call lots of draw commands at once)Jasoco wrote:Explain what you mean. A map in a tile based game is basically a grid of numbers or letters representing objects to draw. Whether its stored in ASCII or binary.Zorbatron wrote:A good, full game, would not use a grid based numeratical layout for their maps, everyone does not, and should not use this method. Regardless you could load them when the game loads even if you don't have them precompiled. You should really consider making a basic tilemap editor for yourself if you want to make a decent game.
I already have a tilemap editor I made actually.
I should show you guys what I've done with JavaScript, CSS and HTML5. If I can replicate it in LÖVE, I'd be impressed extremely. Especially if it kept a steady 60FPS.
Here's a curious question, at any point is LÖVE going to consider doing basic 3D? I know it's "LÖVE2D" but simple 3D would be awesome. Even if it was just plain old SNES SuperFX style 3D. (Think StarFox) Maybe for the future. Since the program uses OpenGL and stuff and is able to do it very fast.
How does your javascript editor work? Does it compile the resulting map into one image? I would think that if you optimized it slightly, like don't draw things outside the screen, love would easily handle it.
Honestly? A 3D engine coded in lua making calls to 2D drawing commands? Theres something that handles that already, its called a GPU. In other words, doing all that math and crap is, not only slow as hell (although suprisingly faster than I expected), its also useless when you could do it all with a C++ library, or better yet, someone could just include 3D libs and recompile LOVE with it (I'm talking about LOVE users not the dev team).bartbes wrote:This subject has come up before and the answer will be and always has been "the goal is to create an easy-to-use 2D engine", anyway, if you really want 3d you may want to check out gLöve/Löve3D which is floating around in projects and demos. (link on the front page of the wiki)
It's an interesting project gLOVE, but the actual focus and usability of it is like making a house out of sticks and hay.
- Jasoco
- Inner party member
- Posts: 3726
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Graphic layers?
The way I have always made map files in all the iterations of the same engine I have rewritten twice so far uses simple ASCII text, uncompressed (So I can edit it by hand) with numbers or letters representing what should go where when the map is loaded.
In my original QuickBASIC engine, a sample map would have looked like:
The top half represented the tile number to use, the bottom 1's and 0's represented collisions for the player. When the "LoadMap" sub/function was called, it would open the file, read each line, then for/next through each line dumping the individual numbers into multidimensional arrays representing tiles and hit zones. It also had a separate "Detail" map that would place details like the windows and doors overlaying the map. So the original had two layers. Both were composited before the map was shown. It usually took about half a second to fade down, generate the map, copy it to the right screen buffer then fade up.
When I moved onto JavaScript, the map system had to change since loading of files was a bit different. But a sample map from that version looks like this:
The file would be loaded via AJAX and would overwrite the current variables and the map was redrawn. Each colon (:) was used as a splitter and each set of strings was loaded and split to represent each part of the maps tile data. Takes about a quarter second to initially load the map, then less than that each subsequent time once the file was cached.
In this and the current LÖVE version, maps have 5 layers plus two collision maps. As I mentioned, the ground tiles, two lower detail layers and two upper detail layers. (Drawn below or above the player and NPC's or enemies)
The current version of my engine, programmed in LÖVE uses yet another version more reminiscent to the original:
Since Lua doesn't have a Split function and all the examples on the internet for creating one did not work at all, I had to resort to fixed numbers. Each set of four numbers represents the layer, the first two numbers being the tile's X location, the second two the Y. The x and periods at the end are the two collision maps. One for the player, one for the NPC's and enemies. (So I can have areas that the NPC's won't walk onto to help keep them in a confined space and prevent them from getting in your way by blocking doorways.
Obviously none of the methods I use are optimal. But during the development phase it is easier to use plain human readable data. Since I can look at those numbers and see "0300" and think, "Oh, that's a piece of grass". At least until I update my map maker to work with my new format. (Making a map creator is almost as hard as making the game itself!)
The original DOS version. 16 colors. Used multiple screens for flicker free animation and draw-once-and-forget methods. Ran pretty fast, but only the player moved. NPC's were stationery, and battles random. (RPG) 850KB total at last version.
JavaScript version. 5 layers of tiles, weather effects with dark night and rain (Think opening to Zelda: Link to the Past). On-screen enemies that could be hit by your sword. Status bar has hearts for health and money. Fast in Safari, but slow when other things were running. JavaScript is not a good game engine yet until framerates can be solidified. 730KB at last version despite being bigger than the QB version.
The version I am working on in LÖVE. If all goes well, it will be the language I end up using. Runs much faster than the JavaScript version in spite of redrawing every single tile and object every frame. Most of the time keeps a solid 60FPS. Never goes below 30.
Both of the first versions had working scripting systems. I have yet to implement it in the LÖVE version yet.
I have to test my theory, but I bet with a small amount of work, I will be able to make the water animated. (If tile == water, use this animated tile instead)
I will say one thing though, LÖVE use a LOT less memory and resources than Safari with my game running does.
Disclaimer: Yes, I know those graphics look familiar. They're placeholders. The player is Link with a blue tunic. The NPC's are from Dragon Warrior and Final Fantasy 4. The trees are also from FF4 and the grass is inspired by Earthbound. The menu system in the original DOS version was also highly inspired by Earthbound. And while you can't see it, the enemies in the JS version were currently blue and orange Octorocks from the original Zelda. And they drop my own version of rupee's.
In my original QuickBASIC engine, a sample map would have looked like:
Code: Select all
30 30 31 31 31 8 8 8 8 8 31 41 30 30 31 31 30 30 30 30
30 31 1 1 1 9 9 9 9 9 1 41 31 31 1 1 31 31 30 30
30 1 1 1 1 11 11 11 11 11 3 37 34 1 1 1 1 1 31 30
30 1 1 1 1 10 10 10 10 10 3 3 41 1 1 1 1 1 1 31
30 1 1 1 1 1 1 7 7 7 7 7 6 7 7 7 7 7 7 7
30 1 1 1 1 1 1 1 1 7 1 1 41 1 1 1 1 1 1 29
30 1 1 1 1 1 1 1 1 7 1 1 37 34 1 1 1 1 1 30
30 29 1 1 1 1 1 1 1 7 1 1 1 41 1 1 1 1 1 30
31 31 2 32 40 40 40 40 40 4 40 40 40 38 34 1 1 1 1 30
40 40 40 39 1 1 1 1 1 7 1 1 1 1 41 1 1 1 1 30
29 29 29 29 29 1 1 1 1 7 1 1 29 1 41 1 1 1 29 30
30 30 30 30 30 29 29 29 1 7 1 29 30 29 41 29 29 29 30 30
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 1 1 1 1 1 0 1 1 1 0 0 1 1 1 1
1 0 0 0 0 1 1 1 1 1 0 1 1 0 0 0 0 0 1 1
1 0 0 0 0 1 1 0 1 1 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1
1 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 0 0 0 0 1
1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1
1 1 1 1 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1
1 1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 1 1 1
When I moved onto JavaScript, the map system had to change since loading of files was a bit different. But a sample map from that version looks like this:
Code: Select all
mN = "The Village Inn";
mD[0] = ["0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::"];
mD[1] = ["0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "2_3:1:::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::1_5::", "0_3:1:::::", "0_3:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "2_2:1:::::", "0_3:1:::::"];
mD[2] = ["0_3:1:::::", "0_3:1:::::", "2_2:1:::::", "2_3:1:::::", "7_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "0_3:1:::::", "0_3:1:::0_6::0_5", "5_1:1:::::", "0_3:1:::2_6::", "2_3:1:::::", "3_0::::::", "3_0::::::", "4_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_3:1:::::"];
mD[3] = ["0_3:1:::::", "2_3:1:::::", "1_4::::::", "2_4::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "1_3:1:::::", "3_1:1:::::", "5_1:1:::::", "7_1:1:::::3_5", "3_0::::::2_5", "6_0::::0_0::2_5", "3_0::::::2_5", "3_0::::::2_5", "3_0::::::2_5", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_3:1:::::"];
mD[4] = ["0_3:1:::::", "7_0::::::", "4_0::::::", "3_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "3_1:1:::::", "5_1:1:::1_6::", "7_1:1:::::3_6", "7_4:1:::::", "7_4:1:::::", "7_4:1:::::", "7_4:1:::::", "7_4:1:::::", "3_0::::::", "5_0::::::", "4_0::::::", "3_0::::::", "0_3:1:::::"];
mD[5] = ["0_3:1:::::", "3_0::::::", "5_0::::::", "3_0:1::3_2:::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "3_1:1:::0_7::", "3_3:1:::::", "7_1:1:::2_7::", "4_2:1::4_2:::", "4_2:1::6_2:::", "4_2:1::2_1:::", "4_2:1::4_2:::", "4_2:1::6_2:2_8::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "1_3:1:::::"];
mD[6] = ["0_3:1:::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "3_3:1::4_2:0_8::", "3_3:1::5_2:::", "3_3:1::6_2:2_8::", "4_3:1::4_2:::2_2", "4_3:1::6_2:::", "4_3::1:4_0:::0_0", "4_3:1::4_2:::", "4_3:1::6_2:2_8::", "1_2:1:::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::"];
mD[7] = ["0_3:1:::::2_5", "3_0::::::2_5", "3_0::::::2_5", "4_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "4_3:1::4_2:0_8::", "4_3:1::5_2:::", "4_3:1::6_2:2_8::", "0_4:1:::::", "3_0:::1_1:::", "3_5::1::::", "4_6::::::", "4_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::"];
mD[8] = ["7_4:1:::::", "7_4:1:::::", "7_4:1:::::", "3_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_5::::::", "6_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::2_2"];
mD[9] = ["3_2:1::0_8:::2_2", "3_2::1:4_1:::0_0", "3_2:1::2_8:::", "3_0::::::", "3_0:1::1_0:::", "2_0:1::2_13:1_4::", "2_0:1::4_13:2_4::", "3_0::::::", "3_0::::::", "5_0::::::", "3_0:1::0_1:::", "3_0::::::", "3_0::::::", "0_5::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_3:1:::::"];
mD[10] = ["0_3:1:::::", "4_6::1::::", "4_6::::::", "0_6::::::", "0_6::::::", "1_1::1::::1_4", "1_1::1::::2_4", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "0_6::::::", "2_6::::::", "3_0::::::", "3_0::::::", "3_0::::::", "6_0::::::", "3_0::::::", "3_0::::::2_2", "0_3:1:::::"];
mD[11] = ["0_3:1:::::", "3_0::::::", "3_0::::::", "4_0::::::", "3_0::::::", "2_0:1::2_13:1_3::", "2_0:1::4_13:2_3::", "3_0::::::", "3_0::::::", "3_0::::::2_2", "4_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "4_0::::::", "3_0::::::", "3_0::::::", "4_0::::::", "1_3:1:::::", "0_3:1:::::"];
mD[12] = ["0_3:1:::::", "3_0::::::", "5_0::::::", "3_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "6_0::::::", "0_4:1:::::", "3_0::::::", "3_0::::::", "3_0::::::", "5_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_3:1:::::"];
mD[13] = ["0_3:1:::::", "0_2:1:::::", "0_2:1:::::", "3_0::::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "3_0::::::", "3_0::::::", "3_0::::::", "4_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "0_3:1:::::"];
mD[14] = ["0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_2:1:::::", "3_0::::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "5_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "6_0::::::", "3_0::::::", "3_0::::::", "3_0::::::", "6_0::::::", "3_0::::::", "0_3:1:::::"];
mD[15] = ["0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_3:1:::::", "0_2:1:::::", "2_0:1::2_13:::", "2_0:1::4_13:::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_2:1:::::", "0_3:1:::::"];
hitZone[0].x = 16;
hitZone[0].y = 282;
hitZone[0].w = 64;
hitZone[0].h = 40;
hitZone[0].s = 7;
hitZone[0].e = 1;
hitZone[1].x = 400;
hitZone[1].y = 186;
hitZone[1].w = 64;
hitZone[1].h = 40;
hitZone[1].s = 15;
hitZone[1].e = 1;
hitZone[2].x = 400;
hitZone[2].y = 400;
hitZone[2].w = 100;
hitZone[2].h = 100;
hitZone[2].s = 500;
hitZone[2].e = 1;
In this and the current LÖVE version, maps have 5 layers plus two collision maps. As I mentioned, the ground tiles, two lower detail layers and two upper detail layers. (Drawn below or above the player and NPC's or enemies)
The current version of my engine, programmed in LÖVE uses yet another version more reminiscent to the original:
Code: Select all
0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0203_0000_0000_0000_0000_x. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0105_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0202_0000_0000_0000_0000_x. 0203_0000_0000_0000_0000_x. 0700_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0006_0005_x. 0501_0000_0000_0000_0000_x. 0003_0000_0000_0206_0000_x. 0203_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0203_0000_0000_0000_0000_x. 0104_0000_0000_0000_0000_.. 0204_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0103_0000_0000_0000_0000_x. 0301_0000_0000_0000_0000_x. 0501_0000_0000_0000_0000_x. 0701_0000_0000_0000_0305_x. 0300_0000_0000_0000_0205_.. 0600_0000_0000_0000_0205_.. 0300_0000_0000_0000_0205_.. 0300_0000_0000_0000_0205_.. 0300_0000_0000_0000_0205_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0700_0000_0000_0000_0000_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0301_0000_0000_0000_0000_x. 0501_0000_0000_0000_0106_x. 0701_0000_0000_0000_0306_x. 0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0500_0000_0000_0000_0000_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0500_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0301_0000_0000_0000_0007_x. 0303_0000_0000_0000_0000_x. 0701_0000_0000_0000_0207_x. 0402_0402_0000_0000_0000_x. 0402_0602_0000_0000_0000_x. 0402_0201_0000_0000_0000_x. 0402_0402_0000_0000_0000_x. 0402_0602_0208_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0103_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0303_0402_0008_0000_0000_x. 0303_0502_0000_0000_0000_x. 0303_0602_0208_0000_0000_x. 0403_0402_0202_0000_0000_x. 0403_0602_0000_0000_0000_x. 0403_0400_0000_0000_0000_.. 0403_0402_0000_0000_0000_x. 0403_0602_0208_0000_0000_x. 0102_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_..
0003_0000_0000_0000_0205_x. 0300_0000_0000_0000_0205_.. 0300_0000_0000_0000_0205_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0403_0402_0008_0000_0000_x. 0403_0502_0000_0000_0000_x. 0403_0602_0208_0000_0000_x. 0004_0000_0000_0000_0000_x. 0300_0101_0000_0000_0000_.. 0305_0000_0000_0000_0000_.. 0406_0000_0000_0000_0000_.. 0406_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_..
0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0704_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0005_0000_0000_0000_0000_.. 0600_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0202_..
0302_0202_0000_0000_0000_x. 0302_0401_0000_0000_0000_.. 0302_0000_0000_0000_0208_x. 0300_0000_0000_0000_0000_.. 0300_0100_0000_0000_0000_x. 0200_0213_0104_0000_0000_x. 0200_0413_0204_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0500_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0005_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0406_0000_0000_0000_0000_.. 0406_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0101_0000_0000_0000_0104_.. 0101_0000_0000_0000_0204_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0006_0000_0000_0000_0000_.. 0206_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0202_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0202_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0103_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0500_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0600_0000_0000_0000_0000_.. 0004_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0400_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0300_0000_0000_0000_0000_.. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0500_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0600_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0600_0000_0000_0000_0000_.. 0300_0000_0000_0000_0000_.. 0003_0000_0000_0000_0000_x.
0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0200_0213_0000_0000_0000_x. 0200_0413_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0002_0000_0000_0000_0000_x. 0003_0000_0000_0000_0000_x.
Obviously none of the methods I use are optimal. But during the development phase it is easier to use plain human readable data. Since I can look at those numbers and see "0300" and think, "Oh, that's a piece of grass". At least until I update my map maker to work with my new format. (Making a map creator is almost as hard as making the game itself!)
The original DOS version. 16 colors. Used multiple screens for flicker free animation and draw-once-and-forget methods. Ran pretty fast, but only the player moved. NPC's were stationery, and battles random. (RPG) 850KB total at last version.
JavaScript version. 5 layers of tiles, weather effects with dark night and rain (Think opening to Zelda: Link to the Past). On-screen enemies that could be hit by your sword. Status bar has hearts for health and money. Fast in Safari, but slow when other things were running. JavaScript is not a good game engine yet until framerates can be solidified. 730KB at last version despite being bigger than the QB version.
The version I am working on in LÖVE. If all goes well, it will be the language I end up using. Runs much faster than the JavaScript version in spite of redrawing every single tile and object every frame. Most of the time keeps a solid 60FPS. Never goes below 30.
Both of the first versions had working scripting systems. I have yet to implement it in the LÖVE version yet.
I have to test my theory, but I bet with a small amount of work, I will be able to make the water animated. (If tile == water, use this animated tile instead)
I will say one thing though, LÖVE use a LOT less memory and resources than Safari with my game running does.
Disclaimer: Yes, I know those graphics look familiar. They're placeholders. The player is Link with a blue tunic. The NPC's are from Dragon Warrior and Final Fantasy 4. The trees are also from FF4 and the grass is inspired by Earthbound. The menu system in the original DOS version was also highly inspired by Earthbound. And while you can't see it, the enemies in the JS version were currently blue and orange Octorocks from the original Zelda. And they drop my own version of rupee's.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Graphic layers?
Though we're kind of off-topic, you can just compile a C lib in the next version using love.native.Zorbatron wrote:Honestly? A 3D engine coded in lua making calls to 2D drawing commands? Theres something that handles that already, its called a GPU. In other words, doing all that math and crap is, not only slow as hell (although suprisingly faster than I expected), its also useless when you could do it all with a C++ library, or better yet, someone could just include 3D libs and recompile LOVE with it (I'm talking about LOVE users not the dev team).
It's an interesting project gLOVE, but the actual focus and usability of it is like making a house out of sticks and hay.
On topic:
Do you store the map in memory, or the contents of the file, or do you start reading the file over and over again?
- Jasoco
- Inner party member
- Posts: 3726
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Graphic layers?
Me? The .map file is loaded once per screen. When you first enter it. All the variables are loaded into multidimensional arrays:bartbes wrote:Do you store the map in memory, or the contents of the file, or do you start reading the file over and over again?
mapTiles[x][y]
mapDeco1[x][y]
mapHit[x][y]
etc...
And then the file is not touched again until the player comes back.
The map file would also store other map-based variables like hitzones. (Areas the player will enter to activate a script, be it a message box, a cutscene, warping to another map, whatever)
Maps are named x_y.map where x is the mapX location and y is the mapY location. Though that is dependent on a one screen at a time mapping system like Zelda 1 as opposed to a scrolling map which I haven't implemented yet. (Though I bet LÖVE could handle it, especially if it is redrawing everything every frame anyway.)
When the player walks off the edge of the screen, the mapX or mapY variable is added or subtracted depending on the direction and the game reloads whatever map matches those numbers.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Graphic layers?
I don't see the big problem here, in every case I've seen everything just works when you draw the map every frame..
- Jasoco
- Inner party member
- Posts: 3726
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Graphic layers?
That's the thing that amazes me though. That LÖVE is fast enough to draw hundreds of things at once every single frame. Without cheating and making objects that are moved around, or storing stuff in buffers to call all at once.
I suppose if I do a tiny bit of work, I'll even be able to make a scrolling map system that still runs as fast as long as I put in catches to make sure it only draws the tile if it is visible in the window area and not draw it if it is located outside.
I'm still in the texting phase of this new engine. So far it's already surpassed TNTBasic in that I actually have the ability to read and write files. Not to mention the framerate. Whoever did the Mac OS port of LÖVE spared no expense in making it just as fast. Now all they need to do is make a 64-bit version for us Core2Duo users.
I suppose if I do a tiny bit of work, I'll even be able to make a scrolling map system that still runs as fast as long as I put in catches to make sure it only draws the tile if it is visible in the window area and not draw it if it is located outside.
I'm still in the texting phase of this new engine. So far it's already surpassed TNTBasic in that I actually have the ability to read and write files. Not to mention the framerate. Whoever did the Mac OS port of LÖVE spared no expense in making it just as fast. Now all they need to do is make a 64-bit version for us Core2Duo users.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Graphic layers?
For only drawing inside the visual area take a look at love.graphics.setScissor.
Who is online
Users browsing this forum: Google [Bot] and 2 guests