x64 Development

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,164
Reaction score
1,500
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
If we get rid of GDI, that would indeed break a lot of existing add-ons. Is there any sort of migration path to render text or graphics without the GDI? Are there any open-source toolkits for that? It would be a lot of work to migrate off GDI, but I'm willing to tackle it for the XR vessels if I don't have to drop or rewrite the 2D cockpits entirely...
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,306
Reaction score
1,511
Points
203
Location
between the planets
I don't think it would touch the cockpits, they draw using directX, not the GDI. At least if the GDI is what I think it is... the windows UI, right? Yeah, replacing that... ugh, that's a problem! Usually the UI toolkit is part of the graphics engine, but we have an "in-house engine" so to speak, and writing a UI framework is a hell of a lot of work. Writing an actually good UI is damn near impossible. But then, the GDI isn't exactly good, either...
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,297
Reaction score
846
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
Iirc there is an older bit blit method, and a newer, 2d mesh method, for 2d cockpits. The older method--correct me if I'm wrong--is the one relying on GDI.
 

yitianetie

Member
Joined
Mar 24, 2020
Messages
48
Reaction score
14
Points
23
Location
Brittany
Hi,

Nice to see the advancements for the 64 bits port. I am wondering some questions about compiling for Linux (of course, it is not hurry). I dare to imagine that we need an opengl client (artlav has done an impressive work for Orbiter 2010 though not perfect, I remember) for using on a such platform. The problem is that I don't have enough time to experiment compiling but I would be sure a beta tester.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
If we get rid of GDI, that would indeed break a lot of existing add-ons. Is there any sort of migration path to render text or graphics without the GDI? Are there any open-source toolkits for that? It would be a lot of work to migrate off GDI, but I'm willing to tackle it for the XR vessels if I don't have to drop or completely rewrite the 2D cockpits entirely...

Well, we already have the Sketchpad interface which was originally designed to be a GPU driven alternative/replacement for the GDI. And we have spend quite lot of time in a development of the Sketchpad. The Stock MFDs and most other user MFDs are already running with the Sketchpad on a GPU.

At a moment, a complete Sketchpad documentation can be found from the /OrbiterSDK/Doc/gcAPI.chm
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,164
Reaction score
1,500
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Ah yes, the XR vessels use the Sketchpad to render the HUD, at a minimum. However, the XR vessels also make many calls to oapiBlt, and that is part of the GDI, correct? Is there an alternative to that besides the "2D mesh" approach? Granted, I haven't dug into the 2D mesh approach, but it looks quite complex at first glance.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
However, the XR vessels also make many calls to oapiBlt, and that is part of the GDI, correct? Is there an alternative to that besides the "2D mesh" approach? Granted, I haven't dug into the 2D mesh approach, but it looks quite complex at first glance.
Right now, oapiBlt() sends the calls mostly to an auxiliary blitter that's a part of a GPU. But in some cases it can also reroute a call to GDI or to a SketchPad. From the compatibility point of view the best choice is likely a use of SketchPad::CopyRect() or SketchPad::ColorKey() for a panel construction in the old fashion way.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
I just remembered that in D3D9Client there are two sub-projects in /samples/ folder. DX9ExtMFD and GenericCameraMFD those should be included in the repository. But I haven't done any testing in x64 for those modules yet.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,306
Reaction score
1,511
Points
203
Location
between the planets
Iirc there is an older bit blit method, and a newer, 2d mesh method, for 2d cockpits. The older method--correct me if I'm wrong--is the one relying on GDI.
Ugh! That complicates things a bit, unless both methods can be implemented by the graphics client, then it probably wouldn't matter.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
Just to clarify that oapiBlt() is not going to disappear anywhere, using it is perfectly O.K. And the old method of creating panels is also O.K.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
Would you be ok with merging the core and client development into a single repository?

Well, Let's wait a month with that. I can't make any sense out of this Git hellhole. The x64 modifications I made are in the Src package I posted earlier in this thread you could check if there's anything helpful in there, I am not going to upload that to a Git. Meanwhile, I'll try to upload the D3D9Client project (x64 branch) to a GitHub and I try to manage the project there to get my bearings. After I know the Git better we can move the project in the Orbiter repository as you suggested.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
That sounds good. Please don't feel rushed. If there is anything I can help with - git, cmake or otherwise please let me know. Once you are ready to push the D3D9client sources to the Orbiter repo let me know. I'll then add you as a member to the project so you have write access.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
@jarmonik : Regarding the two sub-projects in samples/ folder DX9ExtMFD and GenericCameraMFD, I will take a look at them to make them x64 build-able.
As far as I have seen the trunk/ gets all your x64 changes, so I'll make the changes there, too.
By the way: I think we can remove those old Visual Studio Projects / Solutions for VS2008, VS2010 & VS2012, right?
As far as I know you have been using VS2015 so far, so we keep VS2015, VS2017 & VS2019.
...just to clean it up a bit while we're on it ;)
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,164
Reaction score
1,500
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Well, Let's wait a month with that. I can't make any sense out of this Git hellhole. The x64 modifications I made are in the Src package I posted earlier in this thread you could check if there's anything helpful in there, I am not going to upload that to a Git. Meanwhile, I'll try to upload the D3D9Client project (x64 branch) to a GitHub and I try to manage the project there to get my bearings. After I know the Git better we can move the project in the Orbiter repository as you suggested.

I feel your pain about Git. I've been using it at work for a few years now, but I still much prefer using a GUI for it 95% of the time. There are some free ones out there, but FWIW, I quite like Tower. (y)
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
Not to get tooooo of topic, but using github as another "upstream" service makes thinks even more complicated - some things I blame git for are actually github issues.
"All those 'remote' and 'upstream' questions while still figuring out what a 'squash' or 'stash' means ;) )
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
If you just want to get to grips with git, and don't want your first steps be visible on a github repository, you could simply set up a remote repository on your local machine and then push and pull to your heart's content without anybody noticing if things go wrong. I have a backup repository on a USB drive that I push to occasionally, just in case github melts down and my working repository gets corrupted.
 

kalral

New member
Joined
Nov 22, 2020
Messages
23
Reaction score
14
Points
3
Location
Germany
If you just want to get to grips with git, and don't want your first steps be visible on a github repository, you could simply set up a remote repository on your local machine and then push and pull to your heart's content without anybody noticing if things go wrong. I have a backup repository on a USB drive that I push to occasionally, just in case github melts down and my working repository gets corrupted.
github also has a private repository option and it is not visible to other except for the Repo owner. Can also use that option to practice.
Git GUI clients are nice in Windows unlike Linux. Sourcetree and Smartgit are my preferred clients.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
If you just want to get to grips with git, and don't want your first steps be visible on a github repository, you could simply set up a remote repository on your local machine and then push and pull to your heart's content without anybody noticing if things go wrong. I have a backup repository on a USB drive that I push to occasionally, just in case github melts down and my working repository gets corrupted.
That works fine as long as that repository is only used by one person :D
Once "the source" (I think 'upstream' is the right term) of that copy is changed by another developer things get complicated in my head.
Another level of abstraction is the "fork" (github thing)...
So 1st I make a fork of martins repository - easy, one click,
Then I 'clone' (possibly wrong lingo) a local copy from my github repository...
while developing I like to "update" (possibly wrong lingo) my local copy with changes martin has made in the "original" repository...
That's where the 'remote' and 'upstream' things get confusing at first.

I would love to have a thread (single post) that would describe these steps for contributing to Orbiter[*].

[*] "How to provide a pull request to Orbiter"
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,358
Reaction score
513
Points
153
Location
Vienna
Well, the point is: git is not easy. Far from it. It is THE most complex and unnecessarily complicated tool of all the DVCS systems that came out around 2005. And I agree: Github is not making the situation any better.

However, in terms of features and integration options, it outshines every other VCS by miles.

I think the sad truth is this: people will have to learn how it works before they can contribute. There is no easy way around that, recipes don't work in my experience. You can't teach people to fly a plane by handing them the checklist, either.
 
Top