jgarvin
asked on
Pascal question
Does anyone have any leads on automated or semi-automated tools that can convert High-res Turbo Pascal grapics routines to Windows (preferabaly C++) graphics routines?
The current routines use high resolution EGA graphics that only run in full-screen under Windows. To clarify what the graphics routines are, they do use BGI as a basis, with overlayed routines.
They need to co-exist and operate with other windows programs. I need to convert these to something that acts like a native Windows (NT) program. Of course the current version can be viewed in a window, but only with the program frozen.
I have applications that I need to port, but would like to avoid complete re-writes.
Additional Info:
This is not a game, and to a certain extent, speed on any platform is not of the essence, as the application will be running under NT 4.0 with a Dual 200 MHz Pentium Pro PC and 128 Meg of RAM (though a great deal is already used for system control). The graphics mode is 640x350 (some newer graphics cards do not like this mode). About 70% of the screen is a window with rendered CAD graphics. A smaller window using half of the remaining space represents a variable zoomed area of the larger graphic region.
Our graphics mode is 1280x1024 on a 21" monitor. This application must coexist (both viewable at the same time) with a window that is nominally 550x600 pixels.
The current routines use high resolution EGA graphics that only run in full-screen under Windows. To clarify what the graphics routines are, they do use BGI as a basis, with overlayed routines.
They need to co-exist and operate with other windows programs. I need to convert these to something that acts like a native Windows (NT) program. Of course the current version can be viewed in a window, but only with the program frozen.
I have applications that I need to port, but would like to avoid complete re-writes.
Additional Info:
This is not a game, and to a certain extent, speed on any platform is not of the essence, as the application will be running under NT 4.0 with a Dual 200 MHz Pentium Pro PC and 128 Meg of RAM (though a great deal is already used for system control). The graphics mode is 640x350 (some newer graphics cards do not like this mode). About 70% of the screen is a window with rendered CAD graphics. A smaller window using half of the remaining space represents a variable zoomed area of the larger graphic region.
Our graphics mode is 1280x1024 on a 21" monitor. This application must coexist (both viewable at the same time) with a window that is nominally 550x600 pixels.
When you say "High-Res TP Graphics routines"; are we talking about BGI? Or some other grahics library (or something else entirely?).
ASKER
Edited text of question
I can't say I'm totally familiar with BGI, but from what I recall most of the calls map pretty much one-to-one with Windows GDI calls; so writing a wrapper unit that your code would call that would, in turn, call GDI would be one possibility; if you're not doing anything too fancy. I'd be willing to give a hand on creating such a unit if you like.
I also seem to recall from a few years back a commecially available library that was a BGI interface to GDI. This might still be available, though I don't recall seeing it advertized recently. I can try to track down info on that if that sounds like a solution for you.
I also seem to recall from a few years back a commecially available library that was a BGI interface to GDI. This might still be available, though I don't recall seeing it advertized recently. I can try to track down info on that if that sounds like a solution for you.
ASKER
The answer at this time is not quite precise enough as to my options. The response skirts the issue a bit, though I greatly appreciate the offer of additional help. Let me review and ponder the response before I close the question.
Sorry, I have to rate it "poor" for now or it gets closed automatically.
Sorry, I have to rate it "poor" for now or it gets closed automatically.
Forgive me for being a bit miffed, but what were you expecting? A response like: All you have to do is call "Foo;" at the beginning of your original code and everything will transport cleanly from DOS Real-mode direct screen graphics into Windows Protected-mode Windowed graphics? Sorry, ain't no such critter.
I offered to find information on a commercial solution and to provide assistance with rolling your own, 200 points is a lot, but not enough to warrant my just freely posting what amounts to at least several hours work on an interface library.
I offered to find information on a commercial solution and to provide assistance with rolling your own, 200 points is a lot, but not enough to warrant my just freely posting what amounts to at least several hours work on an interface library.
Holy smokes...SLP...don't get all crazy.
I'm sure jgarvin will be more than happy to have you submit
another 'fuller' answer.
I would have rejected your answer too. It is kind of vague.
And a promise of help does not warrant a grade...perhaps
jgarvin wants to see some help first.
I'm sure jgarvin will be more than happy to have you submit
another 'fuller' answer.
I would have rejected your answer too. It is kind of vague.
And a promise of help does not warrant a grade...perhaps
jgarvin wants to see some help first.
ASKER
SLP: My apologies if my response sounded too critical, I did not mean to discount the help you offered. I am not doing the actual coding for this project, but am trying to facilitate it.
The answer had minimal specifics and was a bit "qualified" for me to provide an unqualified "thanks." Not that it is an excuse, but I also was burned 200 points on a non-answer in the past, so I just want to be careful.
And yes, I did have unrealistic hope that there might be some "tool" that would make it fairly easy, or an interpreter/translator that might be able to take chunks of the code and port them to Borland or the other C++. That's why I am here asking the question. I also had no intention of asking for original research. I was hoping to leverage off of something that someone else has used or done before.
Thanks for listening.
The answer had minimal specifics and was a bit "qualified" for me to provide an unqualified "thanks." Not that it is an excuse, but I also was burned 200 points on a non-answer in the past, so I just want to be careful.
And yes, I did have unrealistic hope that there might be some "tool" that would make it fairly easy, or an interpreter/translator that might be able to take chunks of the code and port them to Borland or the other C++. That's why I am here asking the question. I also had no intention of asking for original research. I was hoping to leverage off of something that someone else has used or done before.
Thanks for listening.
ASKER
Adjusted points to 300
What performances are you looking for?
The GDI without Direct... is too slow for games and such.
I know you only want the BGI translated, but there are many ways.
What resolutions do you want?
Any other statistics will be useful.
/// John
The GDI without Direct... is too slow for games and such.
I know you only want the BGI translated, but there are many ways.
What resolutions do you want?
Any other statistics will be useful.
/// John
ASKER
Edited text of question
ASKER
Edited text of question
I'm not too familiar with BGI...
But are these just line, circle, pixel commands wer're
talking about??
If so, I think it would be pretty straight forward to just
convert by hand the drawing commands and the associated
algorithms...
Unless we're talking about thousands of lines of code...
But are these just line, circle, pixel commands wer're
talking about??
If so, I think it would be pretty straight forward to just
convert by hand the drawing commands and the associated
algorithms...
Unless we're talking about thousands of lines of code...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.