PDA

View Full Version : From scratch or component based?



Xorcist
07-11-2002, 09:18 PM
Just wondering how many people prefer to work up their games from scratch ( like this (http://www.eden.rutgers.edu/~xorcist/Win32.txt)) or let Delphi do a majority of the work for them. Where would you draw the line if you had too? Personally if the game doesn't need too much in the way of "windowed" interfaces (i.e. menus, forms, etc.) or a lot of extras, I prefer to do it from scratch. However I know for a fact I can create a game 10x faster using what Delphi has to offer as well as prebuilt components (not just units), which is a big plus even if it means a slightly larger executable.

Zanthos
07-11-2002, 09:24 PM
Depending on your ability, I'd say first time making a game in Delphi, you'll want as much of the work off your shoulders as possible, as for making a line, let something else do it ;) When you finish the project, you *should* be in a programmer frame of mind, which is, explore, rip the code to shreds, figure out what it does and why it does it, you'll learn more and gain confidence by having your first working game(which believe me, not many people do :))

Bobby
07-11-2002, 09:25 PM
Hi, I would go with components because it save's you alot of time and effort. Especially if you want to create the same effect, 10 times, it would be easer to just make a component that would do it for you so the next time you need it you dont have to do as much work. Also it would make the process a heck of alot easier :)

lnpneil
07-11-2002, 09:27 PM
Definitely have to be with components for me right now...

I'm just migrating to Delphi from C and I'm finding prototyping so much quicker and easier - even just testing out vague ideas becomes a piece of cake.

I'll play around and learn how to do it from scratch in Delphi, but I'll always approach the problem with a component based frame of mind (even if I have to write my own components!)

Neil

Alimonster
07-11-2002, 09:33 PM
I do it the hard way without components. However, I'm slowly building up a non-visual, non-VCL library of classes to use. This makes the process a bit easier. I do it the hard way simply due to size - my old web site had a small max limit, so everything I do I have to keep small! There's a big difference there between uploading a 200K file and a 17K file for programs ;).

Useless Hacker
07-11-2002, 09:43 PM
I would usually use components, 'cos otherwise you can't use the DelphiX and PowerDraw libraries (which are mainly component based). Having Said that, I am starting to move away from that and have developed a few non-component-based libraries for things such as DirectInput.

Stevie56
09-11-2002, 12:15 PM
I will start with components basically to get something up and running.

When it's in the shape I want, I will optimize it, remove the unwanted libraries and work on the slow bits, using assembler where necessary.

Some bits, like Delphix's DXDraw and DXTimer, will be left alone. Could use another fast timer, but probably won't improve anything by doing so.

As I write, I tend to have the next time in mind, so everything is designed for adding to a code library. This does lead to unoptimised, but reuasable code. When it works, it goes into the library, then optimisation is done in the application.

iLLUNis
09-11-2002, 12:36 PM
I ll go with the lot and say that i am using mainly components for a game creation and not only....or at least create my own... :!:

Summers Gone
09-11-2002, 01:34 PM
From the scratch and non VCL are different things.

But to answer your question. I dropped VCL long ago, when it comes to use DirectX.

On a side note : Using a Timer for a game is even worse than using the OnIdle event. All you need is a message loop.

TheLion
09-11-2002, 01:47 PM
Can you explain to me how to write a message loop and why the OnIdle event is that bad??? I always use the OnIdle event, because I always thought that was the best thing to use ???

Alimonster
09-11-2002, 02:05 PM
A message loop goes down to core Windows API stuff - you don't get the lovely VCL things. While the VCL is nice, it is a bit less responsive and generates much larger exes than Win32.

The message loop is a pretty simple concept. Whenever Windows does something, it sends a message to every running app which says "this happened. Deal with it as appropriate". Each message is added to a queue, and the message loop takes a message from the queue and processes it (e.g. closing if a WM_QUIT message is received, etc.).

You usually use PeekMessage with games/interactive demos. This takes a message from the queue. You then call TranslateMessage and DispatchMessage. Once you've done this, Windows calls a special function called the WindowProc. This is a big case statement, usually, which might look like this:

function WndProc(HWnd: HWND; Msg: UINT; wParam: WPARAM;
lParam: LPARAM): LRESULT; stdcall;
begin
case Msg of
WM_CREATE:
begin
; // init stuff
Result := 0;
end;
WM_CLOSE:
begin
PostQuitMessage(0); // tell the message loop to finish
Result := 0;
end;
else // some other message
Result := DefWindowProc(HWnd, Msg, WParam, LParam);
end;
end;

The main message loop may look something like this:

while not Finished do
begin
while PeekMessage(Msg,0,0,0,PM_REMOVE) do
begin
if Msg.message = WM_QUIT then
begin
Finished := True;
Break;
end;

TranslateMessage(Msg);
DispatchMessage(Msg);
end;

// todo other update stuff for one game loop here
end;

It's not something that you can dive into without prior reading, though. Try having a look at this tutorial (http://www.alistairkeys.co.uk/gdipart4.shtml) I wrote that explains some of the concepts. Xorcist has also posted some of his Win32 code in another thread around here...

Summers Gone
09-11-2002, 02:55 PM
More like


while not Shutdown do
begin
if PeekMessage(Msg, HDXWindowHandle, 0, 0, PM_REMOVE) then
begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
if WindowsFocused and not Shutdown then Shutdown := not GameLoop;
end;

Sly
22-11-2002, 03:21 AM
Application.OnIdle is exactly the same as providing your own message loop. There is absolutely no difference. Study the VCL source for TApplication to see why. Always remember to set the Done parameter to False so the OnIdle event is continuously triggered.

Summers Gone
22-11-2002, 10:03 AM
No it's not. Even if you only consider the VCL-Overhead just to have a window and use OnIdle, theres a difference.

Xorcist
22-11-2002, 10:35 AM
Always remember to set the Done parameter to False so the OnIdle event is continuously triggered.



What if (because this is what I do when making games that utilize components) you don't set Done := False but rather in OnIdle just have a call to the main game loop procedure, inside of which there is an infinite loop, that loops until the game is terminated. The program should then only re-enter OnIdle on it's way out of the game loop which at that point is terminating the application. Just wondering if any problems might arise... I don't believe OnIdle will ever get the chance to be called again

Sly
02-12-2002, 03:18 AM
Xorcist: Because you are not being nice to message handling. By setting Done to False and allowing it to return normally, you are correctly handling any Windows messages that the application receives. Message handling is something that a lot of people tend to ignore. Maybe it's because the VCL hides most of the message handling that people are not even aware of the necessity of it. Play nice with Windows and it will play nice with you.

Summers Gone: Ok, so there is a difference in executable size, but functionality-wise there is no difference. Performance and functionality is no different. I've done the tests.

Xorcist
02-12-2002, 10:29 AM
Sly, you might have to re-explain that to me. I'm not sure I'm getting it all. I never set Done := False because I never leave Application.OnIdle (I immediately enter a seperate infinite loop). All my message handling is done through periodic calls to Application.ProcessMessages. Which I would assume would allow Windows to handle any messages it needs to. How is this different than setting Done := False? From what I understand, Application.OnIdle only gets called externally once and by setting Done := False it basically recalls itself until Done := True. Where exactly is the message handling done in that case? If no specific calls to Application.ProcessMessages are made.

Sly
02-12-2002, 11:17 PM
TApplication.Run basically works like this:

1. Have we finished? If yes, end application.
2. Are any messages waiting in the message queue? (PeekMessage)
3. If yes, process them. (GetMessage) If received a WM_QUIT, then set finished flag.
4. Call OnIdle event handler.
5. If Done is True then wait for the next message. (WaitMessage)
6. Go to step 1

You say that you call Application.ProcessMessages in your own loop. This roughly simulates the normal message loop. Sure this may work, but ProcessMessages is a hack that allows an application to seem responsive when the application has entered into an extrememly long loop. It is not intended for constant usage. What I'm getting at is there is a recommended way to write Windows applications at the low level of message processing and using the OnIdle event and setting Done to False is the corresponding method if you are using the VCL in your application.