Here is what I would do.
Have a number of quads on the screen the size of a tile and textured with the tile textures to represent the world.
Moving the quads around is cake.
When new stuff is about to come into view make new quads, and apply the appropriate textures.
When stuff goes off screen you can just get rid of those quads.
The player and other objects can be handled the same way as long as zbuffering is off.
This way you don't have to manually blit textures to the screen every frame which seems to be killing you performance for some reason.
This should run at a billion frames per second on shit hardware.
Tell me if you don't understand I'm psleepy so...
EDIT:
For optimal performance, draw all quads that have the same texture in one go, then switch textures and draw a new batch.
EDIT2:
If this is kinds above your lvl thats cool, I dunno much about java or whatever the "Graphics" class is but if it's hardware accelerated it should be slamming even with your code.
Java Tile Engine Super Slow
Author
James,
That's probably something I'll try as well. What you're talking about sounds like OpenGL... the Graphics object is part of Java's stock library, from a part called the AWT (Abstract Windowing Toolkit). From what I seem to understand, it's not hardware accelerated, or else it wouldn't be so slow even with the code that's taking place right now, but I could very easily be wrong. (I probably am.)
That aside, I do see what you are saying and I've decided actually before even reading this post after doing more research that it would make sense to get familiar with 2D OpenGL programming and use it in conjunction with LWJGL. I've been wanting to harness the power of OpenGL for quite some time, and now I finally have an excuse to get cracking. And I can directly apply your quad technique once I do so, having already learned a little bit about it in the time I've spent setting up LWJGL. It seems to be wise, as well as a much more powerful alternative than AWT and Swing.
I appreciate the help!
Colton
That's probably something I'll try as well. What you're talking about sounds like OpenGL... the Graphics object is part of Java's stock library, from a part called the AWT (Abstract Windowing Toolkit). From what I seem to understand, it's not hardware accelerated, or else it wouldn't be so slow even with the code that's taking place right now, but I could very easily be wrong. (I probably am.)
That aside, I do see what you are saying and I've decided actually before even reading this post after doing more research that it would make sense to get familiar with 2D OpenGL programming and use it in conjunction with LWJGL. I've been wanting to harness the power of OpenGL for quite some time, and now I finally have an excuse to get cracking. And I can directly apply your quad technique once I do so, having already learned a little bit about it in the time I've spent setting up LWJGL. It seems to be wise, as well as a much more powerful alternative than AWT and Swing.
I appreciate the help!
Colton
You prolly dont even need a wrapper for open gl honestly, it's a pretty small.
It almost seems like it would take the same amount of time to learn to use a wrapper than the use the api itself.
But either way is great.
EDIT:
But I'm not even sure how using the api itself would work out on java so maybe you need a wrapper I'm not sure.
glhf!
It almost seems like it would take the same amount of time to learn to use a wrapper than the use the api itself.
But either way is great.
EDIT:
But I'm not even sure how using the api itself would work out on java so maybe you need a wrapper I'm not sure.
glhf!
That aside, I do see what you are saying and I've decided actually before even reading this post after doing more research that it would make sense to get familiar with 2D OpenGL programming and use it in conjunction with LWJGL. I've been wanting to harness the power of OpenGL for quite some time, and now I finally have an excuse to get cracking. And I can directly apply your quad technique once I do so, having already learned a little bit about it in the time I've spent setting up LWJGL. It seems to be wise, as well as a much more powerful alternative than AWT and Swing.
I do not know what you were doing wrong, but it's definitetly not AWT/Swing to blame. My tile based scroller gets ridiculous high frame rates while being based on pure drawImage() calls of Graphics objects, with a HUD on top as well.
I do not know what you were doing wrong, but it's definitetly not AWT/Swing to blame. My tile based scroller gets ridiculous high frame rates while being based on pure drawImage() calls of Graphics objects, with a HUD on top as well.
Hmm, I would say time the drawing and track the issue down but it will resolve itself when he switches to opengl.
Still interesting to know.
Author
James,
Java has a couple of interfacing libraries for OpenGL, JOGL and LWJGL being the two most popular from what I've seen. You need something of the sort to act as a wrapper for it, but they are very thin wrappers, and you have to know OpenGL to use them anyways, so I'll be learning OpenGL either way.
6510,
Do you mind elaborating a little bit more on your approach to the engine? I'm curious to see how we differed in our constructions.
Colton
Java has a couple of interfacing libraries for OpenGL, JOGL and LWJGL being the two most popular from what I've seen. You need something of the sort to act as a wrapper for it, but they are very thin wrappers, and you have to know OpenGL to use them anyways, so I'll be learning OpenGL either way.
6510,
Do you mind elaborating a little bit more on your approach to the engine? I'm curious to see how we differed in our constructions.
Colton
6510,
Do you mind elaborating a little bit more on your approach to the engine? I'm curious to see how we differed in our constructions.
Sure, but a bit diffcult because my stuff is spreaded over various framework and concrete game classes.
You already posted a few of your classes. Do you have a simple ready-to-debug Eclipse project at hand ? I could take a look if I dont have to set it up by myself.
Btw what is "slow" ?
One thing that could be a problem would be incompatible color models, but just a blind guess.
Author
6510,
I have a package in a zip archive with all of the classes and images that comprise the tile engine so far, but unfortunately I haven't been using Eclipse, just the command line. Recently, I've made the switch to Netbeans since I've begun to use LWJGL. Would you still be willing to take a look if I place here the zip archive with the classes? I imagine it would be fairly easy to import into an Eclipse project, but I understand if you don't want to take the time to do so. Thank you very much for your time!
Colton
I have a package in a zip archive with all of the classes and images that comprise the tile engine so far, but unfortunately I haven't been using Eclipse, just the command line. Recently, I've made the switch to Netbeans since I've begun to use LWJGL. Would you still be willing to take a look if I place here the zip archive with the classes? I imagine it would be fairly easy to import into an Eclipse project, but I understand if you don't want to take the time to do so. Thank you very much for your time!
Colton
Okay, I took a quick look at it. The main differences to my approach are:
1. tile size
Your screen is 1280x768 with a tile size of 14 pixel, giving you more than 4900 calls of drawImage() for each and every frame
I am using 1024x768 with tiles of 64 pixel, resulting in only 192 calls.
2. tile rendering
You render the whole map each time.
I have an additional side column and row operating as scroll buffer. That means I dont have do redraw the whole map unless the player moves more than the tile size of 64 pixel. Before that you just take a different view window of the tile back buffer and draw it to the visible buffer in one call. Oh well, I am pretty bad in explaining...
1. tile size
Your screen is 1280x768 with a tile size of 14 pixel, giving you more than 4900 calls of drawImage() for each and every frame
I am using 1024x768 with tiles of 64 pixel, resulting in only 192 calls.
2. tile rendering
You render the whole map each time.
I have an additional side column and row operating as scroll buffer. That means I dont have do redraw the whole map unless the player moves more than the tile size of 64 pixel. Before that you just take a different view window of the tile back buffer and draw it to the visible buffer in one call. Oh well, I am pretty bad in explaining...
Author
Okay, I took a quick look at it. The main differences to my approach are:
1. tile size
Your screen is 1280x768 with a tile size of 14 pixel, giving you more than 4900 calls of drawImage() for each and every frame
I am using 1024x768 with tiles of 64 pixel, resulting in only 192 calls.
2. tile rendering
You render the whole map each time.
I have an additional side column and row operating as scroll buffer. That means I dont have do redraw the whole map unless the player moves more than the tile size of 64 pixel. Before that you just take a different view window of the tile back buffer and draw it to the visible buffer in one call. Oh well, I am pretty bad in explaining...
Actually, that makes a lot of sense... I'm going to have to recreate this section of the renderer and maybe redesign the entire approach to it and use something like 32 pixels for the tile size... for my game engine, 64 would be a little too big in order to capture what I want for the game, but 32 would make sense. It was looking too small for me anyway. But now I have a clearer view on how to implement the thing thanks to you... I appreciate the help very much! I'll post it here once it's been redesigned for future viewers to see, and hopefully it will work better as a result.
Best regards,
Colton
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
