Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Low level access to OpenGL ES

Author
Message
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 28th Jun 2013 16:06
Link
I've got an idea for a game and a small company is interested in marketing it and helping with music etc, but they want me to use AGK. I was planning to use the OpenGL ES 2.0 API directly, with SDL for input etc. If I use AppGameKit instead, will it be possible just to request that AppGameKit sets up the display for OpenGL rendering then "stays out of the way" while I use OpenGL calls directly?
Back to top
Profile PM Website
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 28th Jun 2013 18:45
Link
That would sort of defeat the purpose of using AGK.

And I strongly suspect that it would not really be possible.

Once you start AppGameKit, it takes over handling device and user inputs.

Maybe if you never called the AppGameKit Sync() function, you might be able to bypass AGK. But I wouldn't put my hopes on it.

What do you have against using the full functionality of AppGameKit?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 28th Jun 2013 20:01
Link
I shouldn't have called it staying out of the way, I do want AppGameKit to handle input, audio, general housekeeping etc and for it to provide me with a display to render on, and maybe a buffer flip function. I could also use any convenience functions it provides to make it easier to upload textures, set up buffers and/or build shader programs, that sort of thing. But for the actual rendering I want to be able to have full control over the GLSL shader code, creating meshes, setting up transform matrices and rendering calls such as glDrawArrays.

Provided I stick to what OpenGL ES 2.0 supports I think it should work the same on all the platforms AppGameKit supports, and more, so I don't think it's necessary for AppGameKit to provide an alternative API on the grounds of portability. OpenGL with programmable shaders is enormously flexible and powerful, and if AppGameKit tried to support all that flexibility with an alternative API it would be huge.
Back to top
Profile PM Website
XanthorXIII
AGK Gold Backer
13
Years of Service
User Offline
Joined: 13th May 2011
Location:
Posted: 28th Jun 2013 23:50
Link
But using AppGameKit is the best part. Having to avoid OpenGL calls and building a game with it is awesome.
We also have a Version 2 funded through Kickstarter on the way. I would check it out and donate to it. Tier 2 is pretty easy to code for if you are doing it in C++.
Back to top
Profile PM
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 29th Jun 2013 01:35
Link
I would also like my game to run on Linux (including Raspberry Pi). And I want to do most of my coding in Linux, that's what I'm used to. I think that will be possible with AppGameKit targeting Android, but having to upload the app to my phone or tablet for every test run isn't as convenient as being able to test and develop on the same PC.

I don't mind writing two sets of classes for input, audio etc, but having to write two versions of all my rendering code as well will mean lots of extra work, and seems unnecessary when all the platforms support OpenGL ES 2.0 or a compatible version of full OpenGL.

I'm on a very low income, and more into the open source ethos, so before investing in AppGameKit, I'd like to know that I can either use it in conjunction with OpenGL's API or be able to find out more about its 3D API in adance.
Back to top
Profile PM Website
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th Jun 2013 02:43
Link
Quote: "I would also like my game to run on Linux"


We do not currently support Linux. From your list of requirements I would say this would be your biggest hurdle to using AppGameKit for your project.

Quote: "will it be possible just to request that AppGameKit sets up the display for OpenGL rendering then "stays out of the way" while I use OpenGL calls directly?"


In theory, yes, but you should know that I'm not aware of anyone that has done this nor have I tried to do it myself. Where normally AppGameKit examples will tell you to call agk::Sync() you would instead call agk::Swap(). The former renders all of AGK's sprites, 3D objects, etc and then flips the buffer. The latter only flips the buffer (they both also do some audio and input housekeeping). I think that if you handle all the OpenGL draw calls, state changes, and image binding then agk::Swap() would work for your purposes.

Quote: "I could also use any convenience functions it provides to make it easier to upload textures, set up buffers and/or build shader programs, that sort of thing"


That I'm less sure about, combining AGK's images and shaders with your draw calls I can't guarantee will work. AppGameKit does split shaders into their own class, but it has hooks into the AppGameKit camera (for the view matrix) and images (for custom UV offsets that AppGameKit images use), so they would likely override anything you set.
Back to top
Profile PM Email
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 29th Jun 2013 15:18
Link
Quote: "We do not currently support Linux."

That's a shame. Have you ever considered a port? I think it would actually be quite easy.
Quote: "Where normally AppGameKit examples will tell you to call agk::Sync() you would instead call agk::Swap(). The former renders all of AGK's sprites, 3D objects, etc and then flips the buffer. The latter only flips the buffer (they both also do some audio and input housekeeping)."

Is AppGameKit basically single-threaded, or are there separate threads behind the scenes which agk::Sync(), er, syncs? I would definitely want to make my game logic independent of frame rate by using threads. If AppGameKit is single-threaded it will make it difficult to do that but if, on the other hand, it does manage its own threads to separate rendering, game logic and input, that might make it impossible to put one's own OpenGL calls on the right thread?
Back to top
Profile PM Website
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th Jun 2013 22:53
Link
Quote: "Have you ever considered a port? I think it would actually be quite easy."


To be honest I haven't done any compiling on Linux so I have no idea what would be involved, not even sure if I can compile a single binary that will work on all distros?

Quote: "Is AppGameKit basically single-threaded"


The rendering is all single threaded since OpenGL is not thread safe. All the OpenGL calls would have to be on the main thread but it's feasible you could have game logic on a separate thread if you created some kind of abstraction layer between the two threads. So instead of your game logic making OpenGL calls it would queue up drawing for your main thread to process.
Back to top
Profile PM Email
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 29th Jun 2013 23:37
Link
Paul, it would be good if you could provide T2/3 access to the OGL, DX and OAL contexts. I was pleased to see GetMemblockPtr() in the latest definitions. Things like this would make it easier for applications running on higher-performance systems to do very smart things. Currently, we're a bit restricted by having to cater for various wombat phones. I think AppGameKit is much less suited to producing big PC games than DB Pro was (is).

As far as threads goes - it's fine for game logic and AI, except on slow single-core processors, where using threads is actually slower because of context-switching. Only ancient PC or Mac machines would suffer from this, but a lot of Android devices would.

Where is the frame-rate controlled if (say) I set it to 120 fps? Where exactly is the frame delay introduced? Does sync() wait on a timer before returning?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Back to top
Profile PM Website
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 30th Jun 2013 00:02
Link
Quote: "To be honest I haven't done any compiling on Linux so I have no idea what would be involved, not even sure if I can compile a single binary that will work on all distros?"

Ah yes, it can be a bit difficult to support several distros with closed source, but if you built against Ubuntu LTS that should cater for the majority of users. How games using it are distributed would be up to 3rd party developers, but Steam support might be a good idea.

The most commonly used build tools (gcc, GNU make) are much the same as on Android, and Eclipse is also an option, but most people rely on some other front-end to generate Makefiles nowadays. I wouldn't recommend autoconf/automake to someone new to Linux development though! Have you any experience of CMake?
Back to top
Profile PM Website
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 30th Jun 2013 00:18
Link
Quote: "The rendering is all single threaded since OpenGL is not thread safe. All the OpenGL calls would have to be on the main thread but it's feasible you could have game logic on a separate thread if you created some kind of abstraction layer between the two threads. So instead of your game logic making OpenGL calls it would queue up drawing for your main thread to process."

That could work, but the way I understand agk::Sync() works it would be difficult to do quite the way I had in mind.

I think it's better if input can be separated from rendering too, otherwise a complicated scene could cause poor response to controls and add further detriment to the playability. I've also heard of some old phones with a slow fill rate that limits them to 30fps no matter how simple the scene being rendered. With such a wide range of hardware to support I think it's very important to make gameplay independent of the frame rate, so I'm surprised AppGameKit doesn't really support that well.

This sort of thing is my main concern rather than wanting to use extra cores for more performance.
Back to top
Profile PM Website
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 30th Jun 2013 02:12
Link
Quote: "it would be good if you could provide T2/3 access to the OGL, DX and OAL contexts"


I think wglGetCurrentContext would work on Windows, but I see what you mean.

Quote: "Where is the frame-rate controlled if (say) I set it to 120 fps?"


agk::Swap() will block if necessary.

Quote: " I think it's very important to make gameplay independent of the frame rate, so I'm surprised AppGameKit doesn't really support that well."


The method I would use for this is to use timer based movement, for example instead of moving a sprite 1 unit per frame, you would use agk::GetFrameTime() to find out how long the last frame took and move the sprite someValue*agk::GetFrameTime() to use units per second instead. As long as the frame rate is consistent this method works down to about 20-25fps depending on the type of game.

Quote: "Have you any experience of CMake?"


Unfortunately not, I've been spoiled by Visual Studio and XCode If you know of a good tutorial I wouldn't mind taking a look. Perhaps in the future (once we finish our kickstarter goals) we can look at Ubuntu LTS support.
Back to top
Profile PM Email
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 30th Jun 2013 19:35
Link
Quote: "The method I would use for this is to use timer based movement, for example instead of moving a sprite 1 unit per frame, you would use agk::GetFrameTime() to find out how long the last frame took and move the sprite someValue*agk::GetFrameTime() to use units per second instead. As long as the frame rate is consistent this method works down to about 20-25fps depending on the type of game."

That's probably the best approach for my new game where threading isn't available or controllable, but it can make it harder to perform collision detection. In other types of game, like Bombz, a fixed frame rate would work better, because the controls are only polled when the main character has moved by a whole tile, so you want that to be synchronised with the main step function. It worked OK in my earlier Python implementation for Linux and Windows, but I used threading in the Android version to make sure my game engine was scalable.
Back to top
Profile PM Website
realh
11
Years of Service
User Offline
Joined: 28th Jun 2013
Location: UK
Posted: 1st Jul 2013 17:10
Link
Quote: "[quote]"Have you any experience of CMake?""


Unfortunately not, I've been spoiled by Visual Studio and XCode If you know of a good tutorial I wouldn't mind taking a look. Perhaps in the future (once we finish our kickstarter goals) we can look at Ubuntu LTS support.[/quote]
I haven't used CMake myself to be honest, and I got the impression it wasn't very well documented, but it's been a while since I looked at it. I suggested it because it seems to be getting quite popular, especially for cross-platform work (it can generate Visual Studio project files or whatever, as well as Makefiles), and I think QtCreator supports it well too, and that it's one of the leading IDEs for Linux (also available for Windows) other than Eclipse.

Speaking of Eclipse, Google are planning to replace it and ant with IntelliJ and gradle respectively for the Android SDK. I hadn't heard of either before I saw the video from Google I/O, but the news about IntelliJ got an enthusiastic round of applause from the audience . They still seem to be focused too much on Java rather than the NDK for my liking though.
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-11-24 15:32:33
Your offset time is: 2024-11-24 15:32:33