# x64 Development

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
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
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

Tutorial Publisher
Donator
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
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
Beta Tester
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

Orbiter Contributor
Donator
Beta Tester
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
Beta Tester
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
Beta Tester
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
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
Beta Tester
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
Beta Tester
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
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
@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

Orbiter Contributor
Donator
Beta Tester
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.

#### kuddel

##### Donator
Donator
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
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
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
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
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"

#### DarkWanderer

##### Active member
Orbiter Contributor
Donator
FYI: GitHub repository CI now has x64 builds published (available in "Artifacts" section after clicking on a build)

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
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.

Replies
101
Views
7K
Replies
74
Views
5K
Replies
13
Views
3K
Replies
10
Views
272
Replies
36
Views
4K