This is an idea that I have been thinking of for a while, Quake (2 and 3) use a DLL for modifications, but for those you need Visual C++ to compile those DLL''s, an alternative for plugins/mods is a scripting language (interpreted, bytecode or otherwise). But I was wondering if it was possible to combine those two, make a scripting language that compiles to a DLL, that would not only be very useful for plugins to a game but you could also dynamicaly create machine-specific optimized DLL''s for your engine on the fly. So I was wondering if it is possible to make a library to create DLL''s, maybe a library with functions like CreateExportedFunction() and AddAssemblerOperandToFunction() If there was such a library, it would be easy(well maybe not easy) to make your ''own'' scripting language to compile to a DLL. It would be incredibly cool if it were possible... Gyzmo ======================= Meddle not in the affairs of dragons for you are crunchy and go well with toast.

After reading it myself I thought I might not have made myself totally clear, I was wondering if it is possible to create DLL''s with several file i/o functions i.e. your game dynamically creates data and writes it to a file and voila a new DLL. So you can create DLL''s without the use of a third-party compiler(i.e. Microsoft''s VC++, Borlands free C++ compiler, etc.)

Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

you might want to take a look at the old QuakeC (QC) source ID released a while back they work on special qc compilable commands and have their own compiler to assemble the values

several other solutions come to mind...to make a dll from scratch would more then likely require a fair amount of asm and PE structure knowledge if you got it you should already know how to solve your problem
you could also tailor your dll''s for free compilers and provide the basic template and a guide to how to modify..such ones are VercterC (spelt right?) or MASM

a more limited method is to have a area in the dll which can be modified with ease via a point-and-click program you make..although this would involve some reversing of your dll to find addresses

finally you could use a script translator that simply takes predefined commands in a text file and translates them to binary files only your prog can understand

eh?

quote: Original post by forgotton_associator
several other solutions come to mind...to make a dll from scratch would more then likely require a fair amount of asm and PE structure knowledge if you got it you should already know how to solve your problem

Forgive me for my ignorance but what is PE knowledge?



Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

You''re almost suggesting a JIT solution (Just-In-Time) as used by Java/Ruby/etc languages to speed up operation.

Your best bet is to compile the script to your own byte code and create a virtual machine to interpret the byte code at run-time. Or, if you''re feeling like you want a sweet debugger, just interpret the lines of code at runtime.

If you really want to make the code faster by making the script compile straight to a DLL then you''re wasting your time if you have to distribute a DLL for Win32 and a SO for linux and so on - that defeats the purpose of scripts as far as portability is concerned which is to provide a single binary unit that executes on all target machines.

JIT solves this by compiling the script to native code on the user machine when they need it. This means that you can download your new script update from a remote server and have it run at native speed on all platforms.

If you like you can delve into the evils of the Win32 PE (Portable Executable, the format of .EXE and .DLL) but your time can be much better spent. Why not use a freely available assembler that you can package with your software? You then convert your script binary unit to the the native ASM language and compile using the assembler. An assembler which immediately comes to mind is TASM (not Turbo Assembler, Table Assembler - it has a nicely reconfigurable back end).

As an interesting aside it''s worth considering what Q3A did. The entire game code was written in C and compiled to QVM format - byte code that is interpreted by the Quake Virtual Machine. iD used the free C compiler LCC and modified the back end to output their QVM format. However, this same C code could be used by MSVC or whatever to compile to a DLL instead of a QVM allowing them to test everything at full speed using the debugger features of their chosen IDE (VS, I''m sure). Then for security reasons, they packaged the result into a QVM using LCC. Quite nice.

In fact, you''re best off using Java for your scripting if you want something like JIT. Apparently Mozilla uses a nice modular Java VM which you can use to your own gains (www.mozilla.org).

as anon poster said PE is the format of a windows 32 executeable or dll its basicly a virtual partition table in the file which splits up dos stubs data code etc

eh?

Been thinkin'' about this for a while. Looking Glass''s scripting system was a bunch of DLLs - COM DLLs. Suppose we wrote a compiler, COMScript, that integrated game interface declarations into it, but compiled to native code? This compiler would have a syntax that''s more meaningful to the designer than the programmer. The reason I''m suggesting this, as Gyzmo noted, is that it would save people from having to write a set of macros for designers to be able to understand how to script, as did Looking Glass. These macros were essentially wrappers of interface calls and pointer manipulations... but they were macros. If you got erros, you had to run to your nearest programmer, who might be in Hawaii by then.