Writing the user interface for Lugaru 2

Parsap
Unregistered
 
Post: #1
So, David (my twin brother) enlisted me to write the UI engine for Phoenix, aka Lugaru 2. I prototyped the system using REALbasic, carefully abstracting the code for drawing pictures and such. You can check it out here: http://blog.wolfire.com/?p=46

Now for the real work: porting this system to SDL/OpenGL. I don't really know much more than the basics of OpenGL and I have never used SDL before. Before I dive in, I want to make sure that I am doing this right. I have a few questions about the SDL/OpenGL way to do things as opposed to REALbasic's.

a) In RB, all of my files have their mask and base image stored separately and are combined in code. I am told that this is not necessary with SDL and can load PNGs straight up. Is that the best way to do it?

b) In RB, all of my images are drawn to 'Pictures'. I'm guessing that in OpenGL, I would draw to textures. Is it a bad idea to have a texture for each control, which are then drawn into another texture representing the window, which is then drawn into a global texture representing the screen? Am I totally offbase?

c) SDL seems to have a lot of drawing commands. Are these worth using, or should I skip that and directly use OpenGL?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
a) yes.
b) that's one way to go.
c) not worth using.
Quote this message in a reply
Member
Posts: 142
Joined: 2002.11
Post: #3
Parsap Wrote:b) In RB, all of my images are drawn to 'Pictures'. I'm guessing that in OpenGL, I would draw to textures. Is it a bad idea to have a texture for each control, which are then drawn into another texture representing the window, which is then drawn into a global texture representing the screen? Am I totally offbase?

This is not the way that I, personally would do it. I would advise storing each interface graphic as a texture, and then rather than drawing all the elements onto another texture, just draw each element as a polygon.

This is how I did it in Argonaut, more or less:

[Image: argo-weapons.jpg]

The justification of this approach is that it requires very little communication between the CPU and GPU to draw a polygon, but much communication to upload a texture.
Quote this message in a reply
Parsap
Unregistered
 
Post: #4
Holmes Wrote:This is not the way that I, personally would do it. I would advise storing each interface graphic as a texture, and then rather than drawing all the elements onto another texture, just draw each element as a polygon.

This is how I did it in Argonaut, more or less:

The justification of this approach is that it requires very little communication between the CPU and GPU to draw a polygon, but much communication to upload a texture.

So basically, draw it directly onto the screen instead of onto another texture first? That doesn't seem practical because you would lose the benefits of double buffering. You would have to calculate your user interface each frame, which in a complex GUI (mine is an exact mirror of OS X) is very expensive. Is that the case? I am not experienced at all in OpenGL.
Quote this message in a reply
Member
Posts: 142
Joined: 2002.11
Post: #5
Parsap Wrote:So basically, draw it directly onto the screen instead of onto another texture first? That doesn't seem practical because you would lose the benefits of double buffering. You would have to calculate your user interface each frame, which in a complex GUI (mine is an exact mirror of OS X) is very expensive. Is that the case? I am not experienced at all in OpenGL.

You wouldn't have to 'calculate' the user interface each frame - just draw it! OpenGL can process a few hundred quads in virtually no time at all, and that is all you'd need for a GUI. Think about it - you've probably got hundreds of thousands of quads in game objects, what are a few hundred going to do? If recomputing the GUI each frame is your concern, you could put it in a display list. Then when you are not updating the interface, drawing it would be essentially free for the CPU, and extraordinarily cheap for the GPU.

However, focusing on speed here is, I think, the wrong emphasis. Odds are your game will not be spending a good portion of its time thinking about the interface at all. It's my opinion, that you should focus on robustness, and simplicity in design. And I think my approach is better in these respects, because by allowing OpenGL to composite your graphics, you get functionality for free that otherwise you would have to program yourself in your blitting routines. Functionality like scaling, blending modes, ect.
Quote this message in a reply
Moderator
Posts: 384
Joined: 2002.08
Post: #6
Parsap Wrote:...in a complex GUI (mine is an exact mirror of OS X)...

Mirroring an operating system can be a very difficult proposition in many ways, most of all that Apple will change the look in the future and then your application will either look:
a) old for people running the new OS
b) weird for people running the older OS if you update your UI to the new OS look (with maybe an added benefit of them feeling 'on the bleeding edge of technology' without having to pay for the OS upgrade)

Overall I would highly encourage you to restyle your UI to be something completely unique to yourself - sure, it's not as compatible with user interface guidelines (mainly the big rule: be consistent), but you could make it really interesting. Weapons leaning up against the large GUI element windows, fuzziness to mimic rabbit fur around the window, etc.

It's just a very tricky proposition to emulate an entire OS... be warned.

KB Productions, Car Care for iPhone/iPod Touch
@karlbecker_com
All too often, art is simply the loss of practicality.
Quote this message in a reply
Parsap
Unregistered
 
Post: #7
Holmes Wrote:You wouldn't have to 'calculate' the user interface each frame - just draw it! OpenGL can process a few hundred quads in virtually no time at all, and that is all you'd need for a GUI. Think about it - you've probably got hundreds of thousands of quads in game objects, what are a few hundred going to do? If recomputing the GUI each frame is your concern, you could put it in a display list. Then when you are not updating the interface, drawing it would be essentially free for the CPU, and extraordinarily cheap for the GPU.

However, focusing on speed here is, I think, the wrong emphasis. Odds are your game will not be spending a good portion of its time thinking about the interface at all. It's my opinion, that you should focus on robustness, and simplicity in design. And I think my approach is better in these respects, because by allowing OpenGL to composite your graphics, you get functionality for free that otherwise you would have to program yourself in your blitting routines. Functionality like scaling, blending modes, ect.

Ah, ok. I guess prototyping it in REALbasic was not the smartest move, because I had to do a lot of double buffering in order to get it fast. It will be a great relief to throw all of that code out and just draw it straight to the screen.
Quote this message in a reply
Parsap
Unregistered
 
Post: #8
funkboy Wrote:Mirroring an operating system can be a very difficult proposition in many ways, most of all that Apple will change the look in the future and then your application will either look:
a) old for people running the new OS
b) weird for people running the older OS if you update your UI to the new OS look (with maybe an added benefit of them feeling 'on the bleeding edge of technology' without having to pay for the OS upgrade)

Overall I would highly encourage you to restyle your UI to be something completely unique to yourself - sure, it's not as compatible with user interface guidelines (mainly the big rule: be consistent), but you could make it really interesting. Weapons leaning up against the large GUI element windows, fuzziness to mimic rabbit fur around the window, etc.

It's just a very tricky proposition to emulate an entire OS... be warned.

Too late, I've already done it. Smile You can check out my prototype here: http://blog.wolfire.com/?p=46 Actually, on second thought, I think you are misinterpretting my "exact OS X mirror" statement. The app is completely themeable and I am certainly not going to ship the game with the OS X theme, simply because Apple's lawyers would make light work of me. Putting fur on the window or anything else would be as simple as creating a new PNG. The idea for the prototype was to ensure that everything behaved exactly the same as OS X, e.g. you can double click an editfield and select a word, or you can click a popup menu and press command-down arrow to select the bottom item, for example. I am tired of incomplete UI implementations in games where you can't drag and drop text or undo and such. It is actually a lot simpler than people think, my prototype took about a week to create, albeit in RB (although the double buffering optimizations and "dirtyRect" and "undirtyRect" tree structures and such I had to create for speed reasons might counteract RB's ease of use).

The final theme of course is going to be something that behaves exactly the same but looks different. I like your idea of rabbits leaning against windows and such, but David and I are probably going to go for a more "serious" UI that is more appropriate for the WolfireNET feature which includes chat rooms, a gameranger style multiplayer interface, a way to purchase extra content, a way to load third party mods, and so on.

The UI in the game will be totally different though, you aren't going to see "modern" windows when you initiate a chat with an NPC or look at your inventory. The UI engine will be the same, however, just a different theme and window properties.
Quote this message in a reply
Moderator
Posts: 384
Joined: 2002.08
Post: #9
Parsap Wrote:Actually, on second thought, I think you are misinterpretting my "exact OS X mirror" statement. The app is completely themeable and I am certainly not going to ship the game with the OS X theme
...
The UI in the game will be totally different though, you aren't going to see "modern" windows when you initiate a chat with an NPC or look at your inventory. The UI engine will be the same, however, just a different theme and window properties.
Good! I misunderstood your goal in this. I thought you were just trying to replicate Mac OS X windows... not a good idea for all of those reasons!

Sounds like you have some big plans for Lugaru 2 - I look forward to playing it!

KB Productions, Car Care for iPhone/iPod Touch
@karlbecker_com
All too often, art is simply the loss of practicality.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  writing a rasterizer NelsonMandella 4 3,475 Jun 2, 2009 07:02 PM
Last Post: NelsonMandella