Other IDE files

[AweTomatic]

Would it be possible for me to use includes and object libs from Lcc Win32 without re-writing the pre-processor directives Dos.h  for example. Many of you here are probably familiar with it.

[CommonTater]

In many cases you can use 3rd party libraries....

There are some you cannot use.  For example those from 16 bit compilers are not going to work.  You will also need to be aware of the 32 or 64 bit division within Pelles... that is you're not going to build a 32 bit program from 64 bit libraries and visa versa.

dos.h ... if it's dealing with DOS Interrupts or direct access to hardware isn't going to work on anything but a DOS system... since win2000 Windows does not allow direct access to hardware. 

Then there's the language thing... C++ libraries often present interfaces that are difficult to use in C... VBasic libraries are even worse...

All that said... if you're dealing with windows compatible libraries (32 or 64) bit it is quite liklely Pelles C can link with them.

The short answer is ... try it and see what happens.

[Bitbeisser]

There are some you cannot use.  For example those from 16 bit compilers are not going to work.  You will also need to be aware of the 32 or 64 bit division within Pelles... that is you're not going to build a 32 bit program from 64 bit libraries and visa versa.

Well, he is explicitly asking for stuff from/for lcc-win32, another compiler based on the original llc, just like Pelle's C, but with a more restrictive license...

But I fear the general answer is still "maybe".

I actually never got around to take a closer look at lcc-win32, as I found Pelle's C back when I needed to look for a target compiler for the (later canceled) (x)Harbour project a couple of years back...

Ralf

[AweTomatic]

Thank you for your response.

Back to the drawing board.

[Bitbeisser]

Thank you for your response.

Back to the drawing board.

Well, someone in here might be able to help you out nevertheless if you would be a bit more descriptive what you're trying to achieve...

Ralf

[CommonTater]

Well, someone in here might be able to help you out nevertheless if you would be a bit more descriptive what you're trying to achieve...

Hey Ralf....

I agree... sometimes it's really helpful to know what you're trying to do....

[AweTomatic]

I started out with a big windbag response about how I was trying to teach myself game graphics primitives and assembly from Tricks of the Game Programming Gurus, and and then it started to feel like that scene from Shanghai Noon where the beautiful Indian chief's daughter tells Roy O'bannan he talks too much, and I'd read further on in the mean time. Eventually I googled some archaic windows graphics function _setvideomode(), and nothing came up, forcing me to conclude that that book written in 1994 is just obsolete.

So I'll have to take a quicker rockier road paved with doubt and uncertainty. 

Sorry to waste your bandwidth. I've got a whole web and a stack of other graphics books to gain a foothold. I'll try the assembly code on a Windows98 SE platform I slapped together just for DOS games. I never really thought I'd think about programming one seriously, and now my non response response is starting to set sail.   

If I do eventually try to compile and link those in, I'll let you know how it turns out. I first taught myself C on DJGPP, and I recall it has a DOS.h, but the assembler uses AT&T syntax. I know people are doing this stuff in DirectX, but I have a learning disability, or impediment by insisting on learning things from the ground up. I like this message board style, all blogs should be this way. 

[CommonTater]

Ok, given that you are trying to "learn from the ground up" by learning tired old stuff nobody uses anymore, I'm going to suggest --in the gentlest way possible-- that perhaps the problem is that you're starting from the wrong place. 

Beginning from DOS is just going to leave you with a head full of old-think that you're going to have to get beyond at some point... holding yourself back is not the way to get ahead... Especially when you realize the way things have changed... Since Win2000 you have no direct access to the hardware so DOS style graphics programming simply isn't going to work. Beginning with Vista, the "DOS" console window cannot be zoomed to full screen without some serious trickery.  Then the final kicker... Windows X64 versions won't even run 16 bit code.
 
... probably not where you want to be.
 
You should probably start by brushing up on C with a couple of console programs then download the Windows SDK and work on learning the Windows API  and some about Winsock networking.  From there you can move on to graphics coding in GDI+ and Open GL and, of course, some Direct x stuff.  You may find OpenGL is attractive because it's multi-platform with implementations for Windows, Linux, Android and Mac.
 
For the comments about ASM... yes it's handy to know some ASM as there are some situations where it is helpful to "talk with chip" ... However; for most things there is very little advantage in programming whole applications directly in ASM.  First; the plain fact is that most of the functions you would be calling from ASM were written in C or C++ anyway. Second; the output of Pelles C (and other compilers) is machine code just like ASM produces, there's no magical "something else" as there is with interpreters like C# or Java.... So long as you're working with a true compiler of reasonable quality (like Pelles) there will be very little --if any-- difference in performance or size between C and ASM.
 
One of the biggest mistakes computer people make is that they think it's hard... so they go about doing everything the hard way...  Reduce your Excedrin bill and just don't go there.
 

[AweTomatic]

I've done all of my recent programming in C++ Windows API using Dev-C++, and I've written a couple of animated screen savers, including 2 classes to simplify blitting and text output, so I'm familiar with Windows API, and the GDI drawing functions, but they tell me nothing about a ray casting engine, back face culling, or geraud shading, and I couldn't even get the simplest ASM code from that book to work with the Pelles C assembler, and I guess the Adrash book is also obsolete, along with the 2 other books. I basically came to the conclusion that I'd wasted a week of spare time reading obsolete material about 15 minutes ago, and that the way to go is to familiarize myself with the monstrous sized DirectX COM objects and adapt example code to that until the light goes on. So no gentleness was necessary. Come to think of it, most people are in to cell phones and the assorted applications, but that doesn't help me turn my games into my games. Yes my C is rusty, and Dev-C++ comes with an OpenGL library, and I guess since you mentioned it Pelles C does too, though I haven't looked at all the header files, since I was mostly interested in the assembler.

Yes, you're 100% right, there's no point in learning x86 assembly to make a single core 286 run fast when the world is running around with laptops that have corei7s in them, SATA6, and DDR3 memory. I have no OpenGL knowledge other than you need a special file to make the application  work, but you can get it off the web. Thank you for your trouble. Perhaps some of the more popular DOS based games will eventually be adapted. Something else on the bucket list. 

I did find assembly intriguing.   

[CommonTater]

Yes, you're 100% right, there's no point in learning x86 assembly to make a single core 286 run fast when the world is running around with laptops that have corei7s in them, SATA6, and DDR3 memory.
...
I did find assembly intriguing.   

It's not that so much... It's more a case that if you take ASM and C, write the same appy in both then run them side by side on identical machines... assuming optimal code in both cases... it's unlikely you'd find any difference worth commenting on.  Seriously for a job that took 3 hours --depending on the job-- one might finish a second or two before the other.  It's not like there's a 2 to 1 difference or something...
 
Yes ASM is intriguing... I used to write Z-80 ASM for cash registers, dabbled in IAPX-88 ASM for a while and even messed with a bit of 68000 code... But ultimately, if you're doing anything of any size it rapidly becomes a huge exercise in tedium... so I moved to Pascal then C... Landing myself here

[AweTomatic]

The motivation was that the book I was studying had specifically X86 assembly instructions, not because I was worried about program execution laps, which was why I downloaded the Pelles C environment. The one game is turn based anyway, but one day I saw a 3D screensaver, and my eyes just rolled, because I was really proud of my screensavers. The other idea is a 1/2 DOOM engine type 1st person shooter 1/2 role playing game.

I don't really see myself as a sharp enough hard core coder to write CPU instructions for a dedicated micro controller, though the idea of using that empty serial mouse port to take some kind of data is also intriguing.

I'll have to use either OpenGL or DirectX, and adapt the code in those obsolete books to teach myself and understand the visual motivation for the game graphics concepts I mentioned. I've had exactly one programming course, a *coughs* a FORTRAN course. Thankfully, the internet programming community has seen fit to populate cyberspace with many C and C++ tutorials.

Thank you for your help, and your comments, and your civility. I think I'll see if they're still putting serial mouse ports on motherboards. 

[CommonTater]

No worries... Good luck on your journey.
 
EDIT: More of an afterthought really... just two more words of advice for you:  "Publication Dates".
 
Cheers!


 

[AlexN]

Would it be possible for me to use includes and object libs from Lcc Win32 without re-writing the pre-processor directives Dos.h  for example. Many of you here are probably familiar with it.

When I found Pelles C the first time (and this is a long time ago), my prefered compiler was lcc-win32 and I could use my sources with Pelles-C without or with minor changes. And now I try to translate my programs when they are ready with lcc-win32, MinGW-GCC, Tiny C Comiper and usually it works without changes with each tool set.
But I don't compiler specific extension, f.e. like operator overloading of lcc-win32.