SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
GLS
Well-known member
I just tested both build configs on both clients and no problems.... but I'm already running the sketchpad displays (at least the ones I finished) so...
Try the debug build and run a debugging session to see where it CTDs.
GLS
Well-known member
Compile, start Orbiter, go to Tools, Attach to process, choose orbiter.exe, Attach, start a scenario, a popup will show upon CTD, choose Break and report were it stops in the sources.
GLS
Well-known member
Yes, I see... I should have warned people to disable it and delete the CRT.dll file after it was "swallowed" by the main vessel... :facepalm: sorry.
GLS
Well-known member
Small update to the display conversion: currently only the DPS display and parts of the PFDs (tapes, ADI and HSI) remain "offline". Plus most text needs to be repositioned as the fonts aren't exactly what they were before. :facepalm:
The ADI and HSI are the ones that I think will hurt the most due to the GDI/Sketchpad2 choice, so I will probably leave those for last and in the meantime commit a version for testing of what is done so far.
---------- Post added at 04:01 PM ---------- Previous post was at 01:39 AM ----------
So, started with the DPS display today. The lines were easy to do, but the text.... in MOGE nothing shows, and in D3D9 it shows, but (like I expected) the sketchpad version of bitblt doesn't use the HALFTONE mode, so it looks like
. I'm open to suggestions.
The ADI and HSI are the ones that I think will hurt the most due to the GDI/Sketchpad2 choice, so I will probably leave those for last and in the meantime commit a version for testing of what is done so far.
---------- Post added at 04:01 PM ---------- Previous post was at 01:39 AM ----------
So, started with the DPS display today. The lines were easy to do, but the text.... in MOGE nothing shows, and in D3D9 it shows, but (like I expected) the sketchpad version of bitblt doesn't use the HALFTONE mode, so it looks like
. I'm open to suggestions.
Last edited:
My opinion is that we should just ditch official support for the inline client. Heck I can't even run it due to my monitor's native refresh rate (120 Hz) and resolution (2560x1440). It's just getting older and older and we're lucky that it still even works.Small update to the display conversion: currently only the DPS display and parts of the PFDs (tapes, ADI and HSI) remain "offline". Plus most text needs to be repositioned as the fonts aren't exactly what they were before. :facepalm:
The ADI and HSI are the ones that I think will hurt the most due to the GDI/Sketchpad2 choice, so I will probably leave those for last and in the meantime commit a version for testing of what is done so far.
---------- Post added at 04:01 PM ---------- Previous post was at 01:39 AM ----------
So, started with the DPS display today. The lines were easy to do, but the text.... in MOGE nothing shows, and in D3D9 it shows, but (like I expected) the sketchpad version of bitblt doesn't use the HALFTONE mode, so it looks like
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 37,616
- Reaction score
- 2,336
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Can't we just create a template mesh in Orbiter and render it with the new beta? The DPS screens change only twice per second, it should not be too painful and with the original logic underneath, we could split the mesh into static and dynamic parts and reduce the rendering times a lot more (by rendering the static parts on a texture first)
GLS
Well-known member
The ideal for the fonts would be having the ability to load a specific font. That way we could make our own and use it.
Using meshes for the characters would require the Sketchpad2 right?
As for pre-drawing stuff, I did some tests awhile back and didn't really find much improvement at all in that. The half dozen lines we have to draw don't compensate the time it takes do copy their "bounding rectangle" from a pre-drawn surface. It seems our static parts are too simple and/or small for any gain.
Using meshes for the characters would require the Sketchpad2 right?
As for pre-drawing stuff, I did some tests awhile back and didn't really find much improvement at all in that. The half dozen lines we have to draw don't compensate the time it takes do copy their "bounding rectangle" from a pre-drawn surface. It seems our static parts are too simple and/or small for any gain.
GLS
Well-known member
I'm pretty much stuck in this Sketchpad conversion: searching old posts I discovered that the oapiBlt() function doesn't work with a skp->GetSurface() sourced SURFHANDLE, hence why it the DPS doesn't work in MOGE (but it works in D3D9 :idk.
As the MFD update drawing is either GDI- or Sketchpad-based, and the later one doesn't work for the DPS display and the big parts of the PFDs, these displays must be kept in GDI for MOGE and (maybe) a Sketchpad2 version will get them to work (faster) in D3D9.
The latest change I did was switching the MDU menu buttons text drawing from GDI to Sketchpad, but I still left the button outline texture... might get rid of that today.
On top of all of this there's the font issue, not only in the DPS display but on all other displays. As of now, the position of most text outputs in all displays (except the DPS) will need to be corrected as the fonts look different in Sketchpad, but I don't want to change about 800 pairs of coordinates now and then have to redo it all over again when a DEU font is available and usable.
So, currently this is the issue I'd like to "fix" first. I can (and want to) make the font, but there's little point in that if then we can't load it, neither from the windows "font folder" nor from "inside" our dll.
As for the "mesh font", I know nothing about this, but if it is about rendering individual letter meshes... it doesn't seem like a good idea to me... at least not better than dumping the MFD system and hiring someone to do the MDU graphics from scratch :lol:.
.As the MFD update drawing is either GDI- or Sketchpad-based, and the later one doesn't work for the DPS display and the big parts of the PFDs, these displays must be kept in GDI for MOGE and (maybe) a Sketchpad2 version will get them to work (faster) in D3D9.
The latest change I did was switching the MDU menu buttons text drawing from GDI to Sketchpad, but I still left the button outline texture... might get rid of that today.
On top of all of this there's the font issue, not only in the DPS display but on all other displays. As of now, the position of most text outputs in all displays (except the DPS) will need to be corrected as the fonts look different in Sketchpad, but I don't want to change about 800 pairs of coordinates now and then have to redo it all over again when a DEU font is available and usable.
So, currently this is the issue I'd like to "fix" first. I can (and want to) make the font, but there's little point in that if then we can't load it, neither from the windows "font folder" nor from "inside" our dll.
As for the "mesh font", I know nothing about this, but if it is about rendering individual letter meshes... it doesn't seem like a good idea to me... at least not better than dumping the MFD system and hiring someone to do the MDU graphics from scratch :lol:.
The sketchpad is locked to three default fonts. "Arial", "Courier new" and "Times new roman". If I recall it's possible to override that behaviour by placing the '*' if the front of the name like "*Tahoma". Another problem is the anti-aliasing that can't to toggled on/off in per font basis.
I suppose we could have gcCreateFont() that would take the name exactly as specified and would have an option to toggle the anti-aliasing on and off for every font separately. If a font is very small it may look better without AA.
In the sketchpad, Fonts are pre-rendered on a texture and a Text on a screen is a dynamic mesh that renders the fonts from the texture. There are some problems in pre-rendering due to sub-pixel precision used in clear type fonts where the borderline pixels are presented in a different color. The color play doesn't play right when the font is re-colorized during rendering and the background is made transparent. Initial color is white on black background.
Also, To have your own special font could be done via texture and a text file containing character locations. (not implemented but possible)
Also, regarding dynamic meshes/mesgroups. Dynamic mesh is not exactly a problem when done properly. For an example the 3D terrain is a dynamic mesh. Right now the problem is that the client doesn't know switch meshes are dynamic and switch ones are not. Presuming all meshes as dynamic would make things worse. Orbiter mesh has a mesh-group flags which could be used to identify dynamic groups.
---------- Post added at 23:51 ---------- Previous post was at 23:47 ----------
Yes, I have heard that oapiBlt() works but it is unstable (not intended to work there it could cause a bad kind of a loop), that's why the sketchpad has CopyRect, StretchRect,...
I suppose we could have gcCreateFont() that would take the name exactly as specified and would have an option to toggle the anti-aliasing on and off for every font separately. If a font is very small it may look better without AA.
In the sketchpad, Fonts are pre-rendered on a texture and a Text on a screen is a dynamic mesh that renders the fonts from the texture. There are some problems in pre-rendering due to sub-pixel precision used in clear type fonts where the borderline pixels are presented in a different color. The color play doesn't play right when the font is re-colorized during rendering and the background is made transparent. Initial color is white on black background.
Also, To have your own special font could be done via texture and a text file containing character locations. (not implemented but possible)
Also, regarding dynamic meshes/mesgroups. Dynamic mesh is not exactly a problem when done properly. For an example the 3D terrain is a dynamic mesh. Right now the problem is that the client doesn't know switch meshes are dynamic and switch ones are not. Presuming all meshes as dynamic would make things worse. Orbiter mesh has a mesh-group flags which could be used to identify dynamic groups.
---------- Post added at 23:51 ---------- Previous post was at 23:47 ----------
I'm pretty much stuck in this Sketchpad conversion: searching old posts I discovered that the oapiBlt() function doesn't work with a skp->GetSurface() sourced SURFHANDLE, hence why it the DPS doesn't work in MOGE (but it works in D3D9 :idk
Yes, I have heard that oapiBlt() works but it is unstable (not intended to work there it could cause a bad kind of a loop), that's why the sketchpad has CopyRect, StretchRect,...
GLS
Well-known member
Just committed the new Sketchpad displays... at least the ones that were possible. Both PFDs and the DPS display are still GDI in MOGE, as they need stuff not available in Sketchpad. The GDI DPS display is now a tiny bit faster as I removed some unnecessary stuff from it. In D3D9, the PFDs are still missing the main parts, and the DPS display still has the "forbidden" oapiBlt() call (and still looks like c**p), but this situation should improve as SSU starts using Sketchpad2 soon.
The text is still +/- out of place everywhere until the font issue is cleared. In all honesty, I don't really care how it is done, I'd just like to get the displays looking like the real thing. I think a normal SSU font (like Arial, etc) would be preferable in order for it to be easy to use in all "non-DPS" displays. In the DPS display, because it's +/- like a grid, I think the char copy-paste from a bitmap works (don't how good or bad it is speed wise). Jarmonik, I tried the "*" trick (thanks!) but it doesn't seem to work in MOGE... unless Martin changes it...
A way to do this would be editing one of the default fonts to look like we want it to... but I don't think most users would appreciate us changing their Arial or Times New Roman. :lol:
The MDU menus were also changed to Sketchpad. The buttons in the background texture were deleted and it's now all "manually" drawn, enabling the buttons to be white when they need to. I didn't add the MDU port and FC selection in the corners because the whole IDP/MDU interface still needs work to get that info.
The text is still +/- out of place everywhere until the font issue is cleared. In all honesty, I don't really care how it is done, I'd just like to get the displays looking like the real thing. I think a normal SSU font (like Arial, etc) would be preferable in order for it to be easy to use in all "non-DPS" displays. In the DPS display, because it's +/- like a grid, I think the char copy-paste from a bitmap works (don't how good or bad it is speed wise). Jarmonik, I tried the "*" trick (thanks!) but it doesn't seem to work in MOGE... unless Martin changes it...
A way to do this would be editing one of the default fonts to look like we want it to... but I don't think most users would appreciate us changing their Arial or Times New Roman. :lol:
The MDU menus were also changed to Sketchpad. The buttons in the background texture were deleted and it's now all "manually" drawn, enabling the buttons to be white when they need to. I didn't add the MDU port and FC selection in the corners because the whole IDP/MDU interface still needs work to get that info.
That's likely an implementation error on our side. Do you have any numbers ? The y-direction should be accurate. At-least in the stripes of the SurfaceMFD the '+' is perfectly aligned with the tick marks in MOGE and D3D9 where as '-' is about 2 pixels below tick marks in both cases.
---------- Post added at 13:26 ---------- Previous post was at 13:17 ----------
The MOGE is also running with an open source Sketchpad so technically it would be possible to add most of the Sketchpad2 functionality to MOGE there are few problems.
1.) There are no DX7 SDK available any more.
2.) It would require some DX7 knowledge to implement it.
GLS
Well-known member
I don't think the fonts are misaligned. Because the Sketchpad fonts are different from the GDI ones (for one, we weren't using AA before), the text doesn't have the same exact size, and in some places this difference is (very) noticeable.
---------- Post added at 04:35 PM ---------- Previous post was at 01:38 PM ----------
Started adding the D3D9 stuff...
---------- Post added at 04:35 PM ---------- Previous post was at 01:38 PM ----------
Started adding the D3D9 stuff...
I guess it's time to upgrade vs2010. :facepalm:
GLS
Well-known member
So I got the Phobos mesh rendering in the MDUs (which is very weird :lol and got it to move like the ball, but we don't want Phobos there. So, I made a test texture for the ball, which isn't finished but I just want to test stuff for now and later I'll do a better one. I made the texture, but the mesh has to be done by the graphics department... the poles on the texture are on the sides and the equator is that white band in the middle. Only the left half of texture is used. The ball should be 200 meters (or pixels) in diameter, so that the scale number in the code is +/- a round number. I'm not 100% sure but I think the +z axis of the mesh should be aligned with the point (128, 256) of the texture, and the +y axis with point (256, 256). The texture is attached below.
and got it to move like the ball, but we don't want Phobos there. So, I made a test texture for the ball, which isn't finished but I just want to test stuff for now and later I'll do a better one. I made the texture, but the mesh has to be done by the graphics department... the poles on the texture are on the sides and the equator is that white band in the middle. Only the left half of texture is used. The ball should be 200 meters (or pixels) in diameter, so that the scale number in the code is +/- a round number. I'm not 100% sure but I think the +z axis of the mesh should be aligned with the point (128, 256) of the texture, and the +y axis with point (256, 256). The texture is attached below.
- Status
Similar threads
