Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 04-03-2016, 02:51 AM   #166
Havner
Orbinaut
 
Havner's Avatar
Default

Quote:
Originally Posted by martins View Post
 Is this only with the D3D9 client, or also with the latest D3D7 client?

Maybe the OVP change wasn't as uncritical as I thought ...
Happens for me as well (r54), but only with D3D9 (for r53). Windows shows a crash in D3D9 dll. D3D7 works fine.
Havner is offline   Reply With Quote
Old 04-03-2016, 04:44 AM   #167
martins
Orbiter Founder
Default

Does this happen with a recompiled D3D9 client, or are you using a version compiled for a previous beta? If it's the latter, then hopefully only a recompilation will be required.
martins is offline   Reply With Quote
Old 04-03-2016, 06:11 AM   #168
jarmonik
Beta Tester

Default

Looks like there are some Sketchpad fonts created in GraphicsClient::clbkCreateRenderWindow(); but the D3D9Device is not yet initialized and the render windows doesn't exists, so, it is causing a crash in D3D9Client.dll. I suppose it should be possible to allocate the fonts as GDI only at that point and upgrade them to D3D9Fonts after the device is initialized.
jarmonik is offline   Reply With Quote
Old 04-03-2016, 09:25 AM   #169
jarmonik
Beta Tester

Default

Here's a new build that should work with r.54
Attached Files
File Type: zip D3D9ClientBeta23-forRev54.zip (1.70 MB, 91 views)
jarmonik is offline   Reply With Quote
Old 04-03-2016, 01:46 PM   #170
kuddel
Donator
Default

Thanks Jarmo,
that fixed it!
Was that change in Font-allocation unexpected? Or is that going to be the usual sequence? Just out of curiosity, cause I had some random Font- allocation / release issues some time ago which I couldn't reliably reproduce.
kuddel is offline   Reply With Quote
Old 04-03-2016, 03:51 PM   #171
jarmonik
Beta Tester

Default

Quote:
Originally Posted by kuddel View Post
 Thanks Jarmo,
that fixed it!
Was that change in Font-allocation unexpected? Or is that going to be the usual sequence? Just out of curiosity, cause I had some random Font- allocation / release issues some time ago which I couldn't reliably reproduce.
Yes, I wasn't expecting that. In D3D9 we have a graphics "sub-systems" initialized when clbkCreateRenderWindow returns. So, it's not exactly a good idea to create anything graphics related until that. Any font issues you might have had are unlikely related to this one.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-12-2016, 02:08 AM   #172
martins
Orbiter Founder
Announcement New Orbiter Beta Released (r.55, Apr 12 2016)

Change log:
  1. Module class: added callback methods clbkProcessMouse, clbkProcessKeyboardImmediate, clbkProcessKeyboardBuffered for intercepting keyboard and mouse events. NOTE: requires recompile of all Module-based plugins (including graphics clients)
  2. API: new version of oapiGetAltitude that allows to accommodate ground elevation
  3. Lua API: new versions for oapi.get_altitude and vessel:get_altitude to accommodate ground elevation
  4. DeltaGlider: bug fix: typo prevented atm. autopilot from executing
  5. Graphics client: revert to previous splash screen font allocation
  6. Camera: bug fix: ground elevation in ground observer mode could refer to wrong planet.
Re. point 5: after a report of resource leaks regarding Sketchpad resources, I had implemented an allocation counter to keep track of resource allocation, but inadvertently changed the allocation of the splash screen font, which seems to have caused problems. The allocation sequence should now have reverted to the original order.

Re. points 2 and 3: support for altitude queries in the presence of surface elevation has been extended in the C++ and Lua interface. This is in response to this request.

Re. point 1: Jarmo suggested callback functions that can intercept (and optionally block) keyboard and mouse events before they are processed by the standard Orbiter event handler. I've implemented these callbacks now in the Module class. This will allow more comprehensive keyboard and mouse customisation than possible so far.

The downside is that all Module-based plugins, including graphics clients, must be recompiled for this beta.

I don't know how many other addons are affected by this interface change. If this turns out to be a problem I can probably undo this modification. Since I want to get a release candidate out soon, it's maybe a bit naughty to come up with a feature addition so late in the day.
martins is offline   Reply With Quote
Old 04-12-2016, 08:26 AM   #173
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by martins View Post
 The downside is that all Module-based plugins, including graphics clients, must be recompiled for this beta.
No problemo. Done.

Quote:
Originally Posted by martins View Post
  I don't know how many other addons are affected by this interface change. If this turns out to be a problem I can probably undo this modification. Since I want to get a release candidate out soon, it's maybe a bit naughty to come up with a feature addition so late in the day.
Many addons will be affected, but we have to get with the times.

BTW, Martin, before making the final release, would you consider unzipping the textures and elevation data on the fly as proposed here?

Last edited by Enjo; 04-12-2016 at 12:46 PM.
Enjo is offline   Reply With Quote
Old 04-12-2016, 11:43 AM   #174
kuddel
Donator
Default D3D9Client (Beta23.1) for BETA r55

Quote:
Originally Posted by martins View Post
 ...Module-based plugins, including graphics clients, must be recompiled for this beta.
Your wish is my command

Last edited by kuddel; 10-11-2018 at 09:46 PM.
kuddel is offline   Reply With Quote
Old 04-12-2016, 11:56 AM   #175
Havner
Orbinaut
 
Havner's Avatar
Default

Quote:
Originally Posted by martins View Post
 [*]API: new version of oapiGetAltitude that allows to accommodate ground elevation
So while we're on API changes and close to release I'll allow myself to ask/report my finding. And hopefully cause it fixed before the release. I mentioned this in the OrbiterSDK subforum but I suppose you haven't read it.

I developed a small joystick plugin to allow me to support more then one device (plugin itself is irrelevant) and I found I'm unable to control nosewheel steering on the default deltaglider.

From reading the SDK this should be achieved by:
vessel->SetControlSurfaceLevel (AIRCTRL_RUDDER, newVal);

It doesn't work. It sets the rudder, not the NWS. Surprisingly it works for Dan's DGIV, but not for the included one. I have not found any other SDK function to achieve that. And the rudder in the included joystick implementation sets NWS.

The goal of my plugin was to completely mimmick the default Orbiter's joystick implementation (including ROT/LIN and Airfoil switch) and I achieved that, except that one detail.

So there is a bug either in the DG, or the SDK or there needs to be a separate SDK call for setting NWS value. I don't know which.

https://github.com/Havner/orbiter-jo...r/Controls.cpp - setRudder()

Last edited by Havner; 04-12-2016 at 01:01 PM.
Havner is offline   Reply With Quote
Old 04-12-2016, 02:13 PM   #176
martins
Orbiter Founder
Default

Quote:
Originally Posted by Enjo View Post
 BTW, Martin, before making the final release, would you consider unzipping the textures and elevation data on the fly as proposed here?
Yes, in fact the plan was (and is) to keep the entire tileset in a single zip file and extract individual tile files on the fly. This would avoid having to unpack and keep an enormous number of small files on the disk, which can cause various problems.

Doug Beachy has already kindly looked into that and also written and tested code for it. I just haven't yet gotten around incorporating it into Orbiter.

I also wanted to push the concept a bit further. Instead of unzipping a file every time is is requested, I want to keep the unzipped files as a cache. Orbiter would first check the cache if the required file is already present, and request the file from the zip archive if not in the cache.

I also want to keep the interface between Orbiter file requests and the zip file server module reasonably abstract, so that the zip server could eventually be replaced by a network server for remote tileset access, although that's a bit further down the line.

There are a few drawbacks with the zip archive approach, e.g. how to merge multiple zip archives for local tileset replacements (e.g. from base addons), or how to edit individual tiles inside the archive.
martins is offline   Reply With Quote
Old 04-12-2016, 02:33 PM   #177
Enjo
Mostly harmless
 
Enjo's Avatar


Thumbs up

That's great to hear!

Quote:
Originally Posted by martins View Post
 Yes, in fact the plan was (and is) to keep the entire tileset in a single zip file and extract individual tile files on the fly. This would avoid having to unpack and keep an enormous number of small files on the disk, which can cause various problems.
If keeping the same number of compressed files on disk wouldn't be a problem (i.e. each tile would be a zip file), then the below problem wouldn't exist:

Quote:
Originally Posted by martins View Post
 There are a few drawbacks with the zip archive approach, e.g. how to merge multiple zip archives for local tileset replacements (e.g. from base addons), or how to edit individual tiles inside the archive.
I understand that Doug has already written some working code, which is great already, but if you're able to abstract the Orbiter's "TileRequest(x, y, level)" call, then a contributed module could use the other option (read each tile from a separate zip file).


Also, don't get me wrong, but the caching functionality would probably need to be optional, since it kind of kills the purpose of zipping: Firstly, it would bloat the Orbiter installation, and secondly, it would increase the amount of work that the HDD had to do in the same time, when you need it for reading the zip file(s). I can imagine the HDD's head jumping from one sector to another in such scenario, thus slowing down the read process... unless the tile's source was indeed a network share.

[EDIT] One thing to keep in mind, is that in the spirit of the idea of unzipping is, that the unzipped tile should go straight into the memory, and not be placed on the disk.

Last edited by Enjo; 04-12-2016 at 03:10 PM.
Enjo is offline   Reply With Quote
Old 04-12-2016, 02:47 PM   #178
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by martins View Post
 how to merge multiple zip archives for local tileset replacements (e.g. from base addons)
I guess it could be done with archive priority system and a map of the tiles wrt. the multiple archives (once their priority is determined). How to set priorities is TBD, but it could be by the file name, modification date, or alternatively set in a configuration file.
orb is offline   Reply With Quote
Old 04-12-2016, 06:56 PM   #179
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Interesting ... but complicated ...
Enjo is offline   Reply With Quote
Thanked by:
Old 04-12-2016, 08:24 PM   #180
Loru
Moderator
 
Loru's Avatar


Default

How about just storing default earth heightmap files inside the zip and for usser created bases or any modified part using uncompressed wrt files? Uncompressed should just be prioritized over compressed.

One of the advantages of this solution is, that you can delete any addon base and terrain returns to normal automatically.

Last edited by Loru; 04-13-2016 at 05:59 PM.
Loru is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 12:01 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.