6 replies to this topic

[TheSourceOfX]

I have recently started programming my own GUIs into programs and I've come to a bit of a road block. I want to program games with multiple screens (i.e. menu, settings, game board, etc.) and I can't figure out an efficient way to switch between them. My latest idea is to have the program call some drawing function whose location is stored in a pointer. When the screen changes I change the pointer to point to a different drawing function. That way I can easily control the visuals by just changing the value of a single pointer. This method also affords me the ability to make very specific display functions that don't have extraneous if-statements for deciding what to draw. The drawback to this I have found, however, is that calling a function via a pointer is slow. The result is that when something happens that requires the drawing function to be called frequently then there starts to be some major lag. I haven't been able to figure out an alternative way to handle this problem. Does anyone out there have any ideas?

-TheSourceOfX

[WingedPanther]

The answer will tend to depend on a variety of details: language, drawing mechanism, etc. I wouldn't expect using a pointer to a function to cause a significant slow-down, so I wonder if there may be something else in your code that is the actual performance bottle-neck.

Another option would be to have a separate canvas, with a static drawing function for each canvas. Unfortunately, a good solution in C++ is not always a good solution in C, and vice versa, so details will be important.

[TheSourceOfX]

Well in this particular instance I am programming with OpenGL in C++. I've used the Win API to create my window and from there all that happens is that a while loop continuously checks the clock, and at the right time (60 FPS) it calls the drawing function.

What I have noticed is that I can't put very much into my drawing function when it is being called with a pointer as opposed to when I write out a more explicit function call. A more serious, but related, problem however is my input function call. I need the program to know what buttons are being clicked, so every time the windows message function gets a call it sends the data to my own input function, specific to the screen being displayed, via a pointer. That makes capturing things like mouse motion very slow because of how frequently messages are being sent to the program.

I feel as though the problems are related, but I find both to be of equal importance, as I would like to have the ability to program 3D games with more graphics than a hand full of textured cubes.

-TheSourceOfX

[WingedPanther]

Have you done any tests to see if the problem is in the event handling or the screen drawing? I can see the while loop potentially generating a lot of excess logic and slowing everything down, for example. I would rather see a clock object generate a message to the function when it changes, rather than a while loop that might generate multiple messages.

[TheSourceOfX]

The while loop is pretty bare. All it does is check the clock, compare that with the last time it called the display function, and if enough time has passed then it calls the display function and sets the "previous call time" variable to the current time.

I have to have some kind of loop in there just to execute the normal functioning of the program, otherwise it quits. That's a requirement of the Win API setup I have, which I got from a tutorial.

As for the test; I did a simple test of how much I can draw before I notice any lag, and I can put a good deal more onto the screen if I don't use function pointers. However, I still can't get that much. I would think that I'd be able to get a lot of stuff in there because professional video games have much more than I would ever need to put in a game right? Do they do something special that I'm not capable of doing? I thought that C++ would afford me the speed requirements for an amateur OpenGL game.

-TheSourceOfX

[WingedPanther]

I would think that something like a sleep/wake cycle, rather than a check clock/check clock/check clock/draw cycle would be more efficient. I'm not familiar with the Windows API, but my sense is that you've introduced inefficiencies by accident. Warcraft3 has an OpenGL mode and works very nicely with high framerates on modest hardware.

Also, what type of videocard are you using? That can have an impact.

[TheSourceOfX]

I feel pretty good about the video card I use. I play several graphic intensive games with OpenGL on this computer so I wouldn't think it's the video card. I'll try to learn more about the Windows API and see if I can find some way to introduce a sleep/wake cycle. I'll also try and figure out a way to give different screens over to different canvases. Maybe that will offer a more native way to switch between screens (if I've used the word "native" correctly there).

-TheSource