[BETA] Custom Gui V0.8 - Update: 23/08/2007

[dostillevi]

I see you're basically using the file system for mutex, sounds fine. Have you tested transparencies yet? Its probably not necessary, but it would help to integrate the overlay into the general X3 graphics system. I'm curious if XP can handle transparency overlay on what is essentially video, and whether quality is improved when running the transparent overlay in Vista. The transparency programs I currently use in XP display poorly when a video is playing underneath the transparent window.

[Cycrow]

well it uses DirectX to render, so theroectically it can do anything that DirectX can do.

transparencies is not a problem, one of the examples even uses transparent imanages

[sphr]

I *could* be wrong... but I too originally tot that Cycrow just adds a transparent child window over the 3D surface... which is tricky, coz it coudl mess up the message passing system (coz you are interacting with the top window)... though I admit that I'm not familiar with directx (sorry... opengl guy). But if he is actually hijacking the directx render cycle, then it's a different story, coz no new "window" is created. He is probably "drawing" directly onto the same directx surface the game is using (correct me if I'm wrong though,. I'm just speculating, as I do not quite know the all the possibilities with directx)

well, if this is the situation, then it avoided some of the very nasty issues with windows on "special" surfaces (like 3d, video feeds etc). The only cost involve here is the background processing required by the "other" app (not a prob if you have dual core, since x3 essentially only uses 1) and the script engine's processing of the files (which could be costly, but if not done at too high a freq and limit amount written, should be ok). and of coz, the cost of rendering the extra stuff per render cycle.

agree with cycrow that mutex is not needed. cross-process mutex is costly and troublesome and requires cooperation. unless the x3 binary is changed, doubt it can be done up front. If there is a fear of script wanting to write new data but the old data not consumed yet (which I agree *could* happen ... e.g. app reading the file and x3 script cannot write to it), a simple way to workaround (doesn't solve, and come to think of it, may not need to solve) is to emulate a cyclic buffer between producer-consumer style of relationship (x3 script produce, cycrow's app consume). basically, the x3 script can write to series of files by increasing a counter in the filename everytime (and cycle the number at some point). The app can then "consume" each file and deletes it and look for the next number etc. Assuming that the app can consume data faster than the x3 script can produce, even just 2-3 files may already be enough.

Of course, I haven't found the time to download it try (busy week.... and weekend... ) so I can only speculate atm.

[Cycrow]

the rendering process in directx is simlar to that in opengl.

like a story you have a beginning, middle and end. The beginning basiclly sets up the back buffer ready for rendering. The middle adds all the objects to be rendered, then the end finishes th back buffer and presents it to screen.

what this software does, is emulate the DirectX dll. So instead of calling the functions from the directx dll, it calls it from mine, which acts as a proxy between the game and the proper dll.

all functions are simply passed from 1 to another.

what i do, is add stuff before the endscene call


Original

Code: Select all

StartScene
RenderObject1
RenderObject2
RenderObject3
EndScene

Gui

Code: Select all

StartScene
RenderObject1
RenderObject2
RenderObject3
RenderGui
EndScene

so its not just displaying a window over the top, it is part of the render cycle.

and it uses the same direct3d object to render that the game uses and renders onto the same screen

[dostillevi]

that's pretty ingenious Cycrow, props for your innovation!

[Cycrow]

i've updated the Gui DLL.

now includes 2 new examples to show the new features.

which includes animating of the object
and using Custom Borders
also, using varibles from scripts

[Cycrow]

I've got the first Beta version available now.

includes playing of sound files as well.

Also allows Parsing of equations for any number arguments in the Custom Scripts

Also includes a help file for all the commands used in the External Gui Script

[Azz]

Cycrox, it's awesome what you are doing


I'll test your package...

[ChemODun]

Great work.

Can you make passing command line arguments to X3.exe,
like -language xx

[Cycrow]

i plan to make a better lanucher at some point. The one now is just so you can use it

[Cycrow]

New Update, 0.5

- Added Input Block Command
- Added Mouse Control
- Added Rendering of Cursor
- Added Animation Sequences for Sprits
- Animation Block Commands: AnimimationStop, AnimimationRepear, Frame, Animation
- Added CloseOn Event Command block
- Close gui on mouse button
- Added Mouse Over Event
- Change Text Colour
- Added sound
- Added prepend/append text command
- Added Launcher Argument pass through

ChemODun, if you send the arguments to the lancher the same as you do for the x3.exe then it should work

2 new exampels included

Existing:
Example1: Basic display, same as the screen shot, shows text and a texture
Example2: Shows no border, and use of animated sprites
Example3: Shows how to use a custom border, and varibles
Example4: Shows animation sequences

New:
Example5: Shows the new animation sequences for sprites, using sounds and Close Events.
Example6: Menu System, shows use of mouse cursor and the MouseOver event

[Cycrow]

I have lots of ideas for expanding this, but i would like hear any other ideas you might have to add to this as well.

im currently working on command call backs so you can create buttons and controls that can trigger X3 Scripts.

[defiant1]

design it so it can interface with buttons that are put as part of ship cockpits so pilots can turn on/off different things?...or somthin to that effect...

[Cycrow]

theorectically it can already do something like that once i finish the command call backs

[dostillevi]

I was thinking about this today (work is so boring!)

It sounds like this overlay could be a great tool for storyline stuff. For example, there is currently the CCM (com chatter framework) which allows the player to "listen" to com chatter in order to find missions. Using an overlay, the com chatter process could be made much more realistic (by game standards). Instead of sitting in space waiting for a message to arrive, CCM could instead flash an overlay box in the corner of the screen, possibly even with an "incoming message" notification. If done well, this could include video or at least still images of the people involved in the "com chatter" and it could even allow for voice-overs. Further, it could be running all the time, not just when the player purposefully activates the command. In this way, the universe would come alive as the player would be engaged by the game to act.

Incorporating a "story mode" editor in your overlay program might streamline the creating of story elements, allowing people to easily piece together images, text, audio, and have these elements hooked into game events.

Depending on what information this program can read about the game, it might be possible to create customizable interactive informational menus. For example, a person with a lot of factories could customize a menu to display statistics for factory production and profit in real time. In addition, general game notifications could be greatly improved. Instead of just receiving a message that a ship is under attack, an overlay could also display a "warning" message on the screen, and so on. The possibilities are very exciting.

Oh! As far as I know X3 is basically single threaded, so multi-core systems don't see much benefit. Offloading script controls to an external program would allow the computer make use of multi-core environments. For example, in game scripts would only need to poll and write variables while calculations would be sourced out to a secondary program. Everything done in the secondary program (presumably) gets handed to a second processing unit, thus reducing the load on the processor handling the game and improving performance.

[ninjitsumonk]

Well seeing as it allows playing of sound files maybe rather than a message come up, if a ship is under attack(desperate trader in need) the video coms may be down and so people could record their vocals, aplly a bit of software distortion, filters and any other effects and there you go! A message on your comms!

[Cycrow]

well most of what you said is already possible with the current version.

one of the things im planning on making is a custom comms menu, so when you comm a ship, it uses the Custom Gui to display the options along with a portrait of the pilot.

popping up messages is easy.

you can just run scripts in the background that displays the message gui when ever you receive a new message, so it doesn't have to run of player commands.

it would be possible to make it work like MSN, where you get a message notification pop up and you click on it to display the message.

currently it only renders in the center of the screen, but thats only for the demos, it will eventualyl be able to be rendered anywhere

[defiant1]

i think he ment (least for part of it) is that when a message comes in instead of the simple "incomming message" voice you get the voice but at same time you see a little vid window with a rotating icon (mail icon or somthin to that effect) with words "incomming message" being displayed...now that would be neat to do...

[Axeface]

This looks so powerful Cycrow. The first thing that pops to mind is replacing (Overlaying) the race portraits with animated stills of much better models. I am planning on creating some models of the races in Zbrush, would you be interested in seeing them if I did?

Would it be possible to link your gui to the games default one, so when you comm something it overlays the new ones over the top, essentially replacing them?

The other thing that pops to mind (Stated above) is the idea to have things like your current credits/time etc displayed on screen. That would be very handy as it will limit the amount of menu switching we need to do.

[enenra]

You're talking about running it on an extern program. I don't understand much about programming so forgive me if I'm asking something stupid. ^^

Is it possible for such a program to recieve and send data over the internet and display it in real time in X3?

EDIT: I don't mean data about other players and where they are etc. like a multiplayer but more like exchanging statistics or similiar things.