Any progress.... I wonder whether the chess pieces can be moved already by now...

Quote:
Any progress.... I wonder whether the chess pieces can be moved already by now...

Still working on the bottom layer...I'll review what I have and get it released asap.

Quote: Still working on the bottom layer...I'll review what I have and get it released asap.

Thanks.. I am looking forward to it...

Hey guys,

After some struggeling with the basecode, I dont think I'll be able to separate the components I have to produce a release today. I will definitely have something out tomorrow. Taking the day off to code :)

I've actually been a bit busy over the past few days. I've been invited to the GDC in March, so I've been setting up my travel plans. I have started to attend the game developer's meetup in toronto; it's very exciting. If you're in the area, pop in on our next meeting. I'm also looking for a micro ATX motherboard that supports socket 423, so if you have one you're willing to part with, drop me a line.

Cheers,
- llvllatrix

Hey guys,

This time our source tree has grown a little bit; I've added a dialog box that does preloading before OpenGL has started. I've also created the beginnings of what will soon be our WinMain function. If you don’t know much about Win32 and want to get eased into it, this is the place to start. You can find the source tree at:

http://www.eng.uwaterloo.ca/~rramraj/Gamedev/chess_tutorial/src_tree/chess_src.zip

Note that the dialog box you see there is not a typical example of win 32 but the architecture similar. The basic idea is that there is a loop of sorts (in our case the dialog is updated regularly) that makes the update procedure (dlg_proc) run and attempt to process messages sent to the particular window (in this case, the loading window). If the loading window does not process the message, the message gets sent to windows for processing. That’s basically it :)

This particular loading utility has to be the hardest thing I've had to program on this project so far. I redesigned the system at least 5 times before I came up with what you see there. The main problem with designing a pre-loader is the user interface problem.

The problem occurs when you have a process that will take a long time to run (in our case, loading the game). If you simply execute the process your computer will look as if it is frozen; the process will execute and never update the UI for the user to know that things are alright. The solution is to provide some sort of feedback to the user. How do you update the interface while you are executing the process?

There are a few solutions ranging from very easy to overly complex. The easiest solution is to simply post a message saying that the following process will take a long time. Once the user accepts the message, they wait until the process is either over or they become tired waiting and shut off their computer. The hardest solution is multi-threading. With multi-threading, you split your application into parts that are processed at the same time (...well technically, they are processed in little bits at different times but for simplicities sake...). One part would load the program, while the other updates the UI. While this sounds like an ideal solution, it has its headaches.

My solution was a compromise. Basically, the loading bar is separated into chunks or load items. Each item represents a function or subsystem being loaded; like the black chess pieces, for example. The pre-loader will load an item. Once the item is loaded, it will then check to see if the loader's UI has to be updated and update the UI until it doesn’t need to (when the user is finished interacting with it). This way, you can click and drag the pre-loader around the screen between item loading intervals. Once you are done, loading resumes. Since the items take around 1 - 2 seconds to load, the UI looks as if it is moving in real-time (with a bit of jerkiness). One of the nicer things I like about this pre-loader is that it uses the OS to draw the interface. This way we don’t have to wait for anything to load to begin loading stuff (lol).

Here's what I have on my plate for tomorrow:
- use Win32 and OGL to create a window for our game
- Wrap SDL to do the input
- Setup the framework for our contexts
- And finally move away from our basecode

Stay tuned :),
- llvllatrix

I can't download the source link you provided... I think there is something wrong... Can you check the link or reupload it again.... :)

k, code reuploaded, try again.

Quote: Original post by llvllatrix
- use Win32 and OGL to create a window for our game

IIRC, SDL has this funktionality (atleast for fulscreen mode). Since portability seems to be a mater, I would sugest using SDL for the job. Or if you do it win32 anyway, it would be nice if you #ifdef that portion of the code. This would help alot when porting. (At least I would be willing to make the unix stuff when I have the time)

I thought I could move the chess piece already.. :) When I run it, only can see the loading thing, nothing is displayed..

However, the loading thing looks nice... :) you are doing something new here..
Great Job...
I wonder how long it will take again to link all the cpps and display the game like before.... would it increase the time to complete the tutorial....?
Hopefully not .. :)

Quote:
IIRC, SDL has this funktionality (atleast for fulscreen mode). Since portability seems to be a mater, I would sugest using SDL for the job. Or if you do it win32 anyway, it would be nice if you #ifdef that portion of the code. This would help alot when porting. (At least I would be willing to make the unix stuff when I have the time)

I thought I would do it in win32 just to show how it is done...It shouldnt be that hard to port.