I did decide to forego the UI for now, as mentioned in my last post. This shouldn’t be a surprise, given the other thread I made to gather information about level details. I’ve been working out how to efficiently combine the concepts of multiple tilesets and multiple layers when it comes to rendering the tiles themselves. It currently doesn’t fit into the way the renderer is designed. Once I’ve gotten the details ironed out and implemented, I’ll post a screenshot or gif of it.
The level format, at least for storing tile data and all of the layers, has been planned out. It’s not going to be particularly simple for someone to extract useful information from, but I’m not exactly concerned with the ease of making third-party tools. The tile data will still ultimately be stored using ASCII characters so that levels can be edited as plain text without breaking tile data.
Just to show that I’m actually doing something. The level format has been planned out, for tiles at least. I updated the Graal NW converter to match. A scheme for rendering has been devised and I was able to produce something visual. Layers are being worked on now.
It’s kind of disturbing that there are 8192 triangles being rendered to produce this. I may end up having to approach it differently in the end, but we’ll see. There are tradeoffs to every method.
8192 triangles?
A friend experienced lag with the ~6000 triangles on my sine wave page. (I know, it’s really inefficient). (Maybe he was using the whole screen so that’d be ~ 11 000 triangles)
Ok, he did have a game opened but he also has a GeForce 970.
Not sure if this is relevant.
My sine wave page is actually 3 layers of 1 pixel wide lines that are polygons (so 2 triangles each, but you know that). On a 1000 pixel wide browser page, it’s 3000 polygons so 6000 triangles.
That’s WebGL btw, so it’s supposed to be using the graphics card directly.
[QUOTE=2ndwolf;n188793]
8192 triangles?
A friend experienced lag with the ~6000 triangles on my sine wave page. (I know, it’s really inefficient). (Maybe he was using the whole screen so that’d be ~ 11 000 triangles)
Ok, he did have a game opened but he also has a GeForce 970.
Not sure if this is relevant.
My sine wave page is actually 3 layers of 1 pixel wide lines that are polygons (so 2 triangles each, but you know that). On a 1000 pixel wide browser page, it’s 3000 polygons so 6000 triangles.
That’s WebGL btw, so it’s supposed to be using the graphics card directly.
[/QUOTE]
There are a lot of different factors, but I’d say the biggest one is the fact that you have calculations being done every frame for animation. Sine calculations at that, which generally aren’t inexpensive. Then there’s the script interpretation and conversion on top of that. The OpenGL (presumably) implementation may not be designed to efficiently handle that particular type of rendering scenario either, whereas I can fully tailor the renderer to suit my needs.
Here’s some more advanced tile rendering. Given the difficulty of customizing the tile data right now due to no editor, I opted for something a little less exciting visually, but that would still show off what’s going on.
This is the same level rendered with 3 different tilesets and 2 layers. The red strip is the second layer, which as you can see is alpha blended. This is from a 32-bit PNG file.
Some features to note:
Tilesets don’t have to be a fixed size. They can be up to 256x256 tiles in size (4096x4096 pixels) or any multiple of 16 pixels. They don’t have to be square.
Multiple tilesets can be used in a single layer. That’s the case in the screenshot below. The bottom layer is using the updated Graal tileset and the original Zelda tileset.
Up to 8 tilesets can be defined.
Up to 8 total layers (including the bottom one) can be used.
The top 7 layers can be alpha blended.
Tiles do not have to be specified for any particular position on any layer. This includes the bottom layer. This means there could be missing tiles, in which case the blue in the screenshot below would show in that spot. This could potentially be used in the future for interesting effects by changing the base rendering color under the tileset via script.
The alpha blending of that strip hit the frame rate pretty hard, so I’m suspecting that will have to be redesigned later. I’m not entirely sure if any redesign options would even reduce that frame rate hit, though, so perhaps not. Alpha blending is just intensive.
Next is to plan out how to handle displaying of multiple levels and add functionality for scrolling the levels around the display area.
Tilesets don’t have to be a fixed size. They can be up to 256x256 tiles in size (4096x4096 pixels) or any multiple of 16 pixels. They don’t have to be square.
Multiple tilesets can be used in a single layer. That’s the case in the screenshot below. The bottom layer is using the updated Graal tileset and the original Zelda tileset.
Up to 8 tilesets can be defined.
Up to 8 total layers (including the bottom one) can be used.
The top 7 layers can be alpha blended.
Tiles do not have to be specified for any particular position on any layer. This includes the bottom layer. This means there could be missing tiles, in which case the blue in the screenshot below would show in that spot. This could potentially be used in the future for interesting effects by changing the base rendering color under the tileset via script.
[/QUOTE]
[QUOTE=tricxta;n188813]Good job, so much so that I feel like I can put my java engine to rest now and hinge my hopes off this.[/QUOTE]
LOL, it’s funny what some screenshots can do. There is still a LOT of work to be done. So much so that it’s overwhelming and I have to do everything I can to ignore it. Don’t forget my tendencies to not work on it for long periods of time, too.
I’m still working on the multiple level display. Map loading is done, but that was barely anything anyway. It’s hard to find time to work on the project between work, exercise, and other daily tasks. We’re supposed to get snow this weekend, so I probably won’t be going anywhere. Hopefully I can get the level code completed during that time.
Ok, so I can display multiple levels at this point, but it’s not in a dynamic way that allows navigation across a map yet. It would have been to that point, except rendering multiple levels exposed a significant performance flaw in the way this is being rendered currently. I’ve spent most of my development time this weekend researching and trying different methods. This is still ongoing. Getting this right is critical, as it will be the biggest impact to performance by far for the rendering aspect of the engine.
Not exactly the best quality video, but it’s sufficient. Don’t mind the Graal-like jerkiness when moving the levels around. It’s only because it’s going off of my keyboard repeat rate, which is probably like 20-40 keystrokes per second, due to no input system being designed yet. It’ll be smooth later.
The performance problem has been resolved the best way possible that I could come up with. I’ve exhausted every option I’ve come across, and what I chose is the best as far as I can tell. I’m not going to go into technical details because it probably won’t make sense to anyone. Framework now exists to handle any number of levels, however, I haven’t yet came up with the design for dynamically navigating a map. The video is 9 fixed levels rendered for a proof of concept. Navigating a map will require on-the-fly level loading, unloading, and various other calculations. I’ll be working on that now.
Edit: Also, my video card squeals when running this. It’s bizarre.
Full map navigation has been mostly completed. It’s functional, however, it’s currently leaving all levels loaded, which is causing a ton of unnecessary processing. You can see the jerkiness in the video as new levels are loaded, as well as the constant frame rate drop. I’m planning on trying to load levels before they’re immediately needed, in another thread to utilize multiple processor cores. This combined with proper unloading of far away levels should eliminate the loading stutters.
The video is showing navigation across Graal The Adventure’s map, dynamically loaded from a .map (plain text) file. All of the levels have been converted to my format, with the same half normal tileset, half Zelda tileset and 2nd layer alpha blending stripe. (Obviously for testing purposes.)
I’m also going to take a small amount of time to write a debugger for the engine to assist in these efficiency improvements. Knowing what’s going on throughout the engine instead of assuming or trying to manually check will be a huge help.
looks awesome mate.