GameVision SDK 2007

[Pyrogine]

bigsofty:

Impressive framerate in fullscreen. Let me ask, in fullscreen on your machine the simulation runs smooth and consistent correct? GVSDK is designed around frame-based timing which allows the game loop (rendering and game logic) to run as fast as your computer can do it, but the overall simulation should continue to run at a known rate, in the case of the demo will be 35 fps. If the simuation speed goes below/above the desired rate the elapsed time value will be updated to keep the objects moving at a consistent rate. If the simulation rate goes beyond a specified threshold, then elapsed time will max to ONE. This will prevent HUGE jumps in motion if there a large delay between the next frame. The fps display is the overall game loop rate. Do you have vsync turned off?

Well guys I want to again say thanks for your feedback and continued support. This is great as it gives me an opportunity to get some real-world feedback which helps in making a better product.

[bigsofty]

Yes, my vsync was off, the simulation has slight graphical problems, the ship would not stay in the middle of the screen for example. But the game stayed smooth and tried retain its target speed.

[bigsofty]

P.S. as a small (or large) request, simple thread support for scripting (locking, read only global vars) is something... no one seems to be supporting Multi-core (Yes I know I can do it in Delphi)... even though, its obviously the way of the future.

[Pyrogine]

bigsofty:

The ship should eventually come to rest. I need to check for a certain threshold value and if its at this value, set the speed to zero.

Thread support, noted. thanks for the suggestion.

Jarrod

[AthenaOfDelphi]

Just tried it on a crappy PIII with W98 and it didn't work

Kernel.dll: AttachConsole was missing.

It's obvious that its not a bug in your app but a missing feature in the W98 kernel. It's very old so dont bother.

Nothing to do with Win98 because I get the same thing with Windows 2000 Server :-(

[Pyrogine]

AthenaOfDelphi:

Thanks for the test. It looks like AttachConsole is only available on:
Client OS: Windows Vista or Windows XP
Server OS: Windows Server "Longhorn" or Windows Server 2003

according to MSDN: http://msdn2.microsoft.com/en-us/library/ms681952.aspx

I have a simple console class called TGVConsoleWindow that I am using to control the console window. It will try to allocate a console at startup. If that fails this means that you are already running in a console window so it will try to attach to the current one. I assume this is what the normal actions would be for a normal console app. When you run a delphi console app from the command prompt it uses the same window rather than creating a new one. Anybody know more about using the win32 console routines?

[Pyrogine]

chronozphere, AthenaOfDelphi:

If you create a delphi consol app and run it from a dos box, it will use the dos box window already open correct?

if yes, then this is what AttachConsole does. Does any know of any links or any code that will allow me to emulate the AttachConsole function?

[VilleK]

Very cool with an actual Pascal x86 compiler!
Have you used any compiler-generator tools, or is it written from scratch?
How large subset of Delphi language features are you planning to implement?

[Pyrogine]

VilleK:

Thanks. It's written from scratch. A fairly large subset. The standard stuff, oop and more. Eventually C/C++ and Basic.

[Pyrogine]

I finally got a new working build. Phew. I almost went nuts trying to track down one very illusive bug. Ok here is what I’ve got:

1. You download the build here: http://www.softbeat.net/temp/gvsdk2007.zip

2. The compiler can work stand alone or within and editor/IDE such as PSPad ( http://www.pspad.com ). I have been using PSPad to test with and you will find a project file in the archive for this editor. See PROJECT.PPR

3. The compiler uses a simple .INI project file. See PROJECT.INI for details.

4. To make things work from within the editor/IDE, the compiler needs to be called from a batch file. See GVC.BAT and COMPILE.BAT. You should not touch GVC.BAT, but compile.bat is an example of how you setup your batch file for your own project.

5. When you run COMPILE.BAT it will compile the project and if there are any compiler/runtime errors they will be written to a log file and displayed in the console window. If you compile from the editor/IDE you can click on an error line in the log window and it will jump to this line in the editor.

6. GVAPI.PAS is the import unit for the exported API routines and GVSCLASSES.PAS shows all the declarations available from compiled script.

7. See TESTBED.DPR for an example of how to use the API to compile and run a script.

8. It should now run on those OSes that reported a problem. Please let me if you still have problems.

Hopefully by the next build things will be more organized and streamlined to start to include some docs and more examples. There are just so many things in flux at the moment. Since last time there has been such a major effort to get the project to a good and stable point. There is still much work yet to do, but I am most happy with my progress.

At this point you can compile an Object Pascal file to a standalone executable and using the API can do the same thing from within your own code. In fact the compiler EXE was written using the API routines. If you add a unit to the uses statement and this unit has not been registered already in code it will attempt to load the unit from disk. The nice thing about this is that you only need one main source file and you can just have a simple .INI project file. See the OnCompileUseUnitProc callback in TESTBED.DPR. You will notice in the project.ini file you can specify version info and an icon for your executable. GVSClasses.pas shows all the classes, routines and types that are currently available from compiled screen. As you can see there are already an extensive number of classes that allow for some powerful and robust game development.

I hope to release an official public beta in the coming weeks.