×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Registered User
    Join Date
    Jan 2005
    Posts
    11

    Exclamation Making a game without all the GUI APIs

    Hello there. I am a student who likes to program in his freetime. I have yesterday started with Symbian since it has a large target audience and seems like a fast and capable OS to make games for.

    The main focus of the SDK seems to be programming APPS. Those APPS use the native GUI style thus making it look 'bland' and 'yet another program'. In my game I want the player to immerse in it's world immediately.
    Now I couldn't find any pointers on how to immediately exit the native GUI and start your own environment. Does anyone know if this is posible and could you possibly give me any pointers to how? :0

  2. #2
    Registered User
    Join Date
    Feb 2004
    Posts
    14
    Not sure what you are meaning with your enviroment, but im guessing you are doing something like this in your appui's ConstructL

    iAppContainer->ConstructL( ClientRect() );

    to get access to full screen just call instead of the previous

    iAppContainer->ConstructL( ApplicationRect() );

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    11
    Well what I mean is that Series 60 provides the developer of applications with alot of standard elements like textbox, lists. I don't need and want all of these. So I was wondering if I could get rid of them.
    I saw that the Symbian OS specific examples don't make use of these elements whereas the Series60 examples do make use of these. So I was wondering if i make a game I can continue on a Symbian OS specific example and not use a series60 example.

  4. #4
    Nokia Developer Expert
    Join Date
    Apr 2003
    Location
    Finland
    Posts
    425
    Hi

    Try to search forum.nokia with keyword "direct screen". You should findd a documents, e.g. Series 60 Developer Platform 1.0: Direct Screen AccessÂ_ Example v1.1

    Br V

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    11
    Thanks, that helped me alot .

  6. #6
    Super Contributor
    Join Date
    Apr 2003
    Location
    Czech Republic
    Posts
    915
    But even if you will draw everything by yourself you still need the basic framework. Classes like Ceikapplication, ceikappui, ceikdocument, etc...

  7. #7
    Regular Contributor
    Join Date
    Mar 2003
    Posts
    68
    Hi,

    You've posted before about the best way to create a game. I think you'll find that 99% of the (Symbian OS) games written for the Series60 do the following :

    1 Use the standard framework (app, document, appui, view)
    Use the "HelloWorld" example as a guide

    2 The main game screen is created and drawn in the the view class. It doesn't have to use any of the Series60 controls. You can even make the view whole screen if you like. You can create your own graphics for monsters of whatever, and draw them to the view.

    3 Use a CPeriodic to update the screen (view) 10 times a second or so.

    4 Use a second CPeriodic timer to update the internal game "position" in response to keyboard events.

    5 Creating a "buffer" of keypresses, so you can deal with them as and when you want.

    I would recommend using an off screen bitmap (build up the game screen off screen, then blit it all to the screen) to reduce flicker.

    Also note that drawing is much quicker if you only update the bits that have actually changed (you can invalidate areas of the screen to indicate that they need drawing again).

    You really need to use all the standard classes to do things like:
    receive keyevents/menuevents
    respond to events raised by other apps (like being notified when a dialog box pops up, so you can pause your game)

    Hope that helps

  8. #8
    Registered User
    Join Date
    Jan 2005
    Posts
    11
    Ah, ok finally I have disclosure about the generally accepted way of making games . They should put that information in a guide...

    Thank you very much.

  9. #9
    Regular Contributor
    Join Date
    Aug 2003
    Posts
    64
    Hello Kozak17,

    I have my own Symbian-problems to post about, yet I just now looked at your problem. I had the same about a year ago. My game is almost finished but some problems always arise...

    Actually I wanted to tell you how I deal with programming a game on Symbian. I don't know if that's the generally accepted way ( maybe some senior members could approve of that or not...? ) but maybe it helps you.



    So, to begin with, I use the standard framework ( application, appui, document and view/container classes ).
    Then I wrote my own classes ( a graphics engine and, as I called it, a game engine ). Pointers to them are stored in the appui object. They also get initialized in the appui's constructor.

    Then comes an important issue : are you making a realtime or turn-based game? I assume it's realtime, so I use another thread for the realtime-rendering. It's the class 'RThread' and the documentation is quite helpful there.

    When you create a thread you must pass a function and a parameter. I pass a function I wrote myself called 'Main' to make it familiar to a traditional C/C++ program. This function just loops endlessly and tells the game engine to process game logic and the graphics engine to render a new frame.
    It is important that you keep track of the timing : I use 'User::GetTickCount()' for this, there are 64 ticks per second on my Nokia6600 and 10 ticks per second on the emulator.

    As parameter I pass a structure that holds pointers to the graphics engine, game engine, screen pointer to draw to, pointer to keyflags, etc. Pointers to graphics engine etc. are needed so the 'Main' function has access to the graphics engine and can actually "tell to render a frame" etc.
    Everything that needs to communicated between original thread and the second ( realtime-rendering ) thread you created, must be put into the structure you pass as parameter to the second thread.
    I create and start the second thread in my appui's constructor, also.

    Another important detail are keypresses. I keep track of them by using the 'HandleWsEventL' of the appui. By its parameter, you can tell if the event is a keypress or something different. To keep track of keypresses, I use a 32-bit unsigned integer and set and delete flags in it for different keys. I do that in the 'HandleWsEventL'. This keyflag-integer is also stored in my appui class and, of course, also passed to the second thread.


    Basically, it's important to have another thread for realtime rendering and keypresses can be handled by the appui.


    There are other things to say, too. The structure I tried to describe above, is the last I came up with and has not been entirely tested thanks to my current problem I described in my last post. Also there are some details to take care of, such as when your application loses focus,...
    I also wrote a menu engine myself because I also want the whole "player immerses in the game world"-thing. But that would be too much detail now, I think.


    Hoped that helped a bit, if you have questions just ask...

    Victor

  10. #10
    Super Contributor
    Join Date
    Apr 2003
    Location
    Czech Republic
    Posts
    915
    Hi Kozak17,

    what victorh81 described is definitely the best way how to do game programming if you add another thread for sound effects and some assembly for quick graphics you can have pretty good and fast game but it is not the easiest way how to do it...
    If you don't need something special and you want to make just some simple small game you should check RetroBlaster example on Nokia's pages (it is part of 2-D Game Animation Techniques In C++ document - 2DGameAnimS60C_v1_0.zip) and build your game above it...

  11. #11
    Regular Contributor
    Join Date
    Aug 2003
    Posts
    64
    Hello sopta007,

    first, thanks for your approval of my concept I described!

    Since you mentioned sound, I have a question concerning sound. I tried around with sound a while ago ( I think I used 'CMdaAudioPlayerUtility' ) but stopped because it was "too slow".
    What I mean is this : My game runs at 32 frames/second and everytime a sound was played, there was a noticeable pause. Just a very short fraction of a second but enough to cause 'hick-ups'.
    For example, to simulate an engine sound, I would play a short sound over and over again but there would be pauses all the time.

    I figured that using 'CMdaAudioPlayerUtility' was not the fastest way ( I was playing .wavs already which are supposedly the fastest sound files to play because least compressed ).

    So maybe you know how to "play sound fast"? It must be possible, see the N-Gage...

    Thank you for any help!!

    Victor
    Last edited by victorh81; 2005-01-09 at 13:57.

  12. #12
    Super Contributor
    Join Date
    Apr 2003
    Location
    Czech Republic
    Posts
    915
    I believe that I've seen some example about sounds (sound mixer?) at www.newlc.com (check tutorial section)... I've never really tampered with sound more deeply than writing a simple library for playing MODs, so I don't know about any problems with CMdaAudioPlayerUtility as you described them...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×