Beginning A Zelda-style Rpg Game


Capn_Fish said:
OGL supports doing things to individual pixels. What do you think it can't do that it needs to?
I just don't know how to get a pixel. I mean I know you can render with GL_POINTS to draw pixels but how do you modify an exisiting pixel?
 
Last edited by a moderator:
PokeParadox said:
Capn_Fish said:
OGL supports doing things to individual pixels. What do you think it can't do that it needs to?
I just don't know how to get a pixel. I mean I know you can render with GL_POINTS to draw pixels but how do you modify an exisiting pixel?


http://www.opengl.org/documentation/specs/...drawpixels.html
http://www.opengl.org/documentation/specs/...readpixels.html

Although I have no experiencie on drawing and reading pixels using OpenGL. I've read that there are a few ways to do this, and some of them are very slow, others are faster.. But OpenGL is not optimized to draw and read pixels, it's optimized for drawing polygons...
 
Last edited by a moderator:
I haven't read everything now, but the first question which wasn't answered from the first post: 2D or 3D?
For the graphics related questions I would say you should see that the pandora is really fast. But to get a better performance you should write it in OpenGL ES. Fragment shaders would allow effects without having a big impact on the framerate.
 
Maybe not the most popular suggestion, but since you're going to be doing a 2D game you might want to consider it (this model is probably what has been used on any number of 2D console games, just a guess though)

That is to:

- Go with a fixed framerate. If you use the 3D hardware then you probably won't have a hard time generating 30FPS or perhaps 60FPS. This simplifies things a lot; if you have a hard time keeping up then you can add frame skipping, but if you design your game around a certain framerate that's generally sustainable then it'll the movements and animations will line up nicely with whatever you choose.

- Scrap multithreading for in-game entities and instead make timeslicing explicit with the time quantum being one frame. If you need more precision, make N logical frames per 1 drawn frame; something like 60 logical frames per second should give you lots of precision, especially for a 2D adventure game. This may require more state to be stored explicitly, but your entities probably won't have a lot of state anyway. This makes it so synchronization won't be an issue and you'll be able to schedule and reschedule things to fit well with however the game works, rather than being at the mercy of the OS or thread library. It also keeps the logical events nicely lined up with the physical screen redraws - again, this is more of a factor in 2D games.

- For event processing you probably just want to have the interested parties check for whatever events when their timeslice runs. If you want to streamline this more you can make event handler functions/methods that the entities can register with the scheduler and make it handle dispatching the right one before dispatching the main execution function/method.

- Since all of the state has to be externally visible (ie, not stored in local variables) inbetween frames, and since you'd never allow saving/restoring in the middle of a frame, it becomes pretty clean to save/restore everything at known points.

Then you lay out all your per frame stuff, a possible ordering is something like this:

- Render video (tile layers, sprites, with special attention for effects)
- Render audio (depending on what you use you might have another thread taking this off asynchronously, SDL works this way for instance)
- Cycle animation on entities
- Update physics for entities and move them (+velocity, +acceleration, etc) (keep position before frame saved)
- Execute event slices for entities
- Execute normal slices for entities
- Perform collision check test for all entities that want it (you may want to use some binning techniques for speed)
- Execute collision event slices for entities that collide, along with lists of what they're colliding with (include ability to roll back, you may also want to have it test at every point of motion between last frame and current frame, or possibly just as an option for really fast moving things)
- Wait until frame is over

To help you out you'd probably want to throw in ways to communicate with the scheduler to make life easier for you, IE have it control waiting for so many time durations, animations, etc - this works a lot like any other cooperative multitasking environment would. The only burden on you is that you have a hard time limit under which to perform operations. If it becomes too much of a problem then it might be possible to use coroutines (there are some solutions for this), then throw checkpoints in your code to see if you need to give up execution and then yield out. This may seem like brute forcing what threads give you in the first place, but it'll still let you easily synchonize with a frame and easily (and quickly) avoid critical sections. However, it really shouldn't be necessary, because the game logic per-entity should be really short and sweet (not going to have any enormously complicated AI most likely)

This isn't really the most beautiful solution from a modern software engineering standpoint, but will probably suit your game fine. Sometimes programmers get too bogged down in "standard" techniques and it ends up hurting them in the end.
 
So, basically, (if I read you right), you make a big loop in which you run each AI object N times per frame, and then when you're done with that, wait until that frame renders before moving to the next. Is that right?
 
javaJake said:
So, basically, (if I read you right), you make a big loop in which you run each AI object N times per frame, and then when you're done with that, wait until that frame renders before moving to the next. Is that right?
Sort of. Every AI object runs once per "logical frame" (although can run multiple times if certain events trigger). You run N logical frames per physical frame (where N may be 1 if that works well for you). The time you wait isn't waiting for the frame to render, it's making sure that the frame takes a certain amount of time. Otherwise things won't be synchronized, and it's a lot easier to work with a synchronous model than an asynchronous one. For 2D games synchronous is usually fine.
 
Last edited by a moderator:
The model you suggest actually sounds like a really good idea. Here's what I was thinking (but I may drop this in favor for Exophase's idea):

Game engine starts, initializes the map object, which then initializes dependencies for that map. (The "map" would be the main menu, really.) Now the game engine waits for an event to occur. And waits. And waits some more.

A click event is suddenly added to the queue by another thread. The game engine reads this, and passes it to each AI object registered to receive such an event. The MainMenu object, who was the only one to receive this event this time, realizes the click occurred right on the "Options" button. A new map needs to be loaded. It creates a new MoveToMap event in the main even queue, and finishes.

The game engine, not having any more objects to talk to, throws away that event and goes to see if there's a new one. Behold! There is! It's a MoveToMap event, and the AI object registered for such an event is GUI. GUI loads the next map, and returns back to the game engine.

Now, there'd actually be many more events. Transitions from one menu to another would probably not be a new map, but some sort of animation that is updated every 10 milliseconds or so. There would be a timer running on another thread that would be firing off a new TimePassed event every 5 milliseconds, so the GUI object would wait until (timePassedSoFar + timeJustPassed >= animationDelay).

With this model, the only thing that needs to be locked is the event queue. Anything that does run in a separate thread to trigger something at a particular time should create an event to start things rolling.

I was going to have each AI object be its own thread (asynchronous), so that each could receive the event at basically the same time and speed things up, but the signal I'm getting is to avoid threads as much as possible.
 
It's also worth considering that the Pandora is a single-core machine, so having multiple threads won't make things work more concurrent or faster if you're not doing blocking stuff like I/O (like maybe reading files or rendering).

And I'll second and reiterate the points that threads make it easy to have implicit state that is hard to save and load, and that you have little control over how they run, which can lead to some uncanny nondeterminism when you use them to implement game mechanics.
 
tell me if you get stuck with anything but programming, have a lot of story ideas, some puzzle ideas, a few song ideas and could probably draw some things too. I would be more than happy to help.
 
Multiplex said:
It's also worth considering that the Pandora is a single-core machine, so having multiple threads won't make things work more concurrent or faster if you're not doing blocking stuff like I/O (like maybe reading files or rendering).
Well, threading was never really about speed, but about structure. I don't know what you mean about nondeterminism, though, and would like to hear more about pitfalls to avoid.

lootic said:
tell me if you get stuck with anything but programming, have a lot of story ideas, some puzzle ideas, a few song ideas and could probably draw some things too. I would be more than happy to help.
I'd me more than happy to receive that help. :) Give me some time (say, a month or two?) to pull together the engine design, and a very rough story time-line first.
 
Last edited by a moderator:
javaJake said:
Well, threading was never really about speed, but about structure. I don't know what you mean about nondeterminism, though, and would like to hear more about pitfalls to avoid.
I probably assumed a bit too much from the "so that each could receive the event at basically the same time and speed things up" part, never mind.

I haven't really written a lot of threaded applications, but here are some of the things I've encountered with the ones I wrote. I don't know, maybe I just suck at threads;
The pitfalls are mostly where you'd expect, except one tends to fall in them anyway.
Say you have two threads, one moving an object right every second, and one moving it up. You could easily get two up-movements or two right-movements in a row, depending on thread scheduling, making the path it takes partly random.

Or say your game loop consists of sending some messages, and rendering a frame. If you don't explicitly synchronize, there's no telling which of the messages have been processed and which haven't, so you could end up rendering a couple of frames without any messages getting processed, then half of them gets acted on, then a couple messages gets half done in the middle of rendering, etc. You might get the right result, if none of the actions over different threads are order dependent, but it could look a bit jerky. Similarly, if you want the threads to do some actions on shutting down, you have to synchronize them somehow, or you won't know when it's safe to delete stuff the threads may be using, etc.

When you use threading in C++, it's likely you'll be using locks of some sort for shared resources. Say you want to move messages between two queues, with semaphores A and B. If some code that gets called from one thread says CODE
A.wait(); B.wait(); ...; B.signal() A.signal()
and code in another thread says CODE
B.wait(); A.wait(); ...; A.signal() B.signal()
(except probably with try/finally / RAII), you have a heisenbug where very rarely, both threads will randomly get into a deadlock.

A lot of the complexity comes from shared data structures, so it's a good idea to avoid those as much as possible, which is why message passing is a good idea. If two threads try to modify a data structure like a linked list at the same time, the result could be gibberish, and then it'll crash some time later when you're accessing the list, and you haven't got a chance of reproducing it in a debugger. Anything mutable that several threads need access to should be protected by some sort of lock/mutex (preferably by making a thread-safe class).
 
Last edited by a moderator:
Wow, I hadn't thought of the thread syncing problem. I always had in my mind that each thread was its own independant entity and didn't rely on others, but actually that's not true.

The frames may or may not update in sync with another thread controlling character movement, so what you get is either the movement happening to early (jerks forward) or too late (jerks to a stop).

I will definitely have to think about that.

Now I know why I created this *cough* thread.

Edit: The locking issue should not occur for me - the only way I want the threads to communicate with each-other is via events, so that only the event buffer/list/thing is ever locked.
 
javaJake said:
lootic said:
tell me if you get stuck with anything but programming, have a lot of story ideas, some puzzle ideas, a few song ideas and could probably draw some things too. I would be more than happy to help.
I'd me more than happy to receive that help. :) Give me some time (say, a month or two?) to pull together the engine design, and a very rough story time-line first.

YIHO! you have one employee that works for free then. :D
 
Last edited by a moderator:
javaJake said:
sindbad said:
There was a port of python's Twisted to C++ which could be of help. There are some other libraries as well (libevent is for file events for example).
Not quite sure what you're suggesting. I'd rather write in pure C++ for best efficiency and readability, and I won't need to do much with files besides the occasional write for save-states and numerous reads for resources.There is a C++ library inspired by Twisted that allowed easy enough event based programming, but I'm not sure it still is maintained. Could be a good source of inspiration, but I can't seem to find the link.
 
Last edited by a moderator:
<ot>
todd said:
I'm a Java developer by day. Historically a C programmer. "Always" wanted to learn C++.
I'm a javascript-turned-java hobby developer. Java is easy enough for me to understand, but C/C++ leave me screaming at my monitor. :lol:

todd said:
I'm looking forward to seeing another compiled language hit it big. Probably something which lends itself to concurrency on multi-core CPU's. But I wonder whether the days of a single dominant language might be numbered, if not already over by a decade.

In the meantime, here's hoping for a JVM on the Pandora in the near future. Java, JRuby, Jython, Groovy, Scala, you name it.

You didn't ask for my $0.02, but you caught my attention as I seem to find myself in a similar position to yourself.

Sun just released JRE 1.6u10 for ARM! B) Word is it's free for open source projects, too. Only one downside - it's headless, so unless you want it for console apps, it's not going to be terribly useful unless it gets bundled with something else.

I wonder if JIRR+Irrlicht+JRE would work? :unsure:

Unfortunately, my C knowledge and linux knowledge is quite basic, so I'll just have to wait until someone else gets java working. Seems like there's quite a few of us that like java, though.
</ot>
 
Last edited by a moderator:
I'm not a programmer but I tried to make games for gp2x with glbasic. But soon stumbeled against limitations like reading pixelcolour for level tiling.

For 2D games on Pandora, what is the best for object orientated programming language?
 
kin said:
For 2D games on Pandora, what is the best for object orientated programming language?

Probably C++, using the SDL library.
 
Last edited by a moderator:
Back
Top