Need expert advice on many different matters
-
hi! I'm a college student but on spare time like programming, I've been programming since I was ten, and this summer I'm getting my hands on a big C++ programming project. I'm currently on the "planning stage" and need help on the following: First a few things you should know in order to help: --------------------------------------------------- -Most of the coding is to be done on a 486dx2 8MB RAM 800MB HDD notebook, which is able to run W95 and DOS. Graphic mode works. I haven't tried Linux, but I don't think it would be practical, as I need as much HDD I can get for project sample data. -My main goal is efficiency meaning speed (and results, though not relevant here) and compatibility with at least every Windows-DOS PC (allowing 640x480x256) and if possible Linux. -This program will NOT use MFC, but needs to be able to init graphic mode at 640x480x256. I want specifically this as it looks pretty standard for compatibility with older PCs. My problems: ------------ #1: I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory). What should I do about this? Should I use some "graphics.h" or such? #2: I'll be doing heavy HDD I/O as the main task in this program will be file data analysing. I've read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing. Is this true? What would be the most efficient way? #3: I need a very light and very specific Window-GUI (by specific I mean I won't need many controls and they will need to be adapted to the program's needs), so I was thinking of making one of my own. Taking out the "complexity" issue which is being taking care of, the real doubt here is: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines? I point to that perhaps any other GUI already out there uses some other sophisticated techniques which would make them faster anyway... I should add that I'm not thinking of moveable/resizable windows, as it's more about n-criteria sorting flexgrids and checkable filelistboxes... #4: Some libraries already made objects from my project are currently working on VC++. Now, as you know, VC++ won't fit my 486 :), I've thought about "CommandLineTools.exe" (8,5MB) from borland but it seems to lack of some really important libraries such as "conio.h"!?!? (goodbye getch, kbhit :( ) So what I'm asking
-
hi! I'm a college student but on spare time like programming, I've been programming since I was ten, and this summer I'm getting my hands on a big C++ programming project. I'm currently on the "planning stage" and need help on the following: First a few things you should know in order to help: --------------------------------------------------- -Most of the coding is to be done on a 486dx2 8MB RAM 800MB HDD notebook, which is able to run W95 and DOS. Graphic mode works. I haven't tried Linux, but I don't think it would be practical, as I need as much HDD I can get for project sample data. -My main goal is efficiency meaning speed (and results, though not relevant here) and compatibility with at least every Windows-DOS PC (allowing 640x480x256) and if possible Linux. -This program will NOT use MFC, but needs to be able to init graphic mode at 640x480x256. I want specifically this as it looks pretty standard for compatibility with older PCs. My problems: ------------ #1: I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory). What should I do about this? Should I use some "graphics.h" or such? #2: I'll be doing heavy HDD I/O as the main task in this program will be file data analysing. I've read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing. Is this true? What would be the most efficient way? #3: I need a very light and very specific Window-GUI (by specific I mean I won't need many controls and they will need to be adapted to the program's needs), so I was thinking of making one of my own. Taking out the "complexity" issue which is being taking care of, the real doubt here is: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines? I point to that perhaps any other GUI already out there uses some other sophisticated techniques which would make them faster anyway... I should add that I'm not thinking of moveable/resizable windows, as it's more about n-criteria sorting flexgrids and checkable filelistboxes... #4: Some libraries already made objects from my project are currently working on VC++. Now, as you know, VC++ won't fit my 486 :), I've thought about "CommandLineTools.exe" (8,5MB) from borland but it seems to lack of some really important libraries such as "conio.h"!?!? (goodbye getch, kbhit :( ) So what I'm asking
hi, I'd written a program about 3 years ago whose requirements were very similar to urs. Since then I've never programmed in any other language other than VC. Even then, though i've forgotten a lot of things, lemme answer ur queries: 1. The problem with "ALL" OS is that most of them run in protected memory mode, hence they wud not allow u to directly write to memory. But there are ways, and prob'ly they are OS specific. 2. yeah, binary file read/write is almost always faster. 3. u may write ur own library. For 640x480x256, u might be thinking of using SVGA, though I found the SVGA a bit slower - using banking and all those stuff. I am pretty sure old monitors wont support SVGA. 4. Never been into those thins :) 5. As long as u stick to C++, there wont be any incompatibilities, but when jumping to asm, man - there are almost always incompatibilities. 6. For displaying fonts really fast, I'd preffered my own bitmapped fonts rather than the font libraries. 7. Showing BMP's and playing WAV's are pretty easy tasks, u can google for the algos and demo codes. Hope this wud help u. "Do first things first, and second things not at all." — Peter Drucker.
-
hi! I'm a college student but on spare time like programming, I've been programming since I was ten, and this summer I'm getting my hands on a big C++ programming project. I'm currently on the "planning stage" and need help on the following: First a few things you should know in order to help: --------------------------------------------------- -Most of the coding is to be done on a 486dx2 8MB RAM 800MB HDD notebook, which is able to run W95 and DOS. Graphic mode works. I haven't tried Linux, but I don't think it would be practical, as I need as much HDD I can get for project sample data. -My main goal is efficiency meaning speed (and results, though not relevant here) and compatibility with at least every Windows-DOS PC (allowing 640x480x256) and if possible Linux. -This program will NOT use MFC, but needs to be able to init graphic mode at 640x480x256. I want specifically this as it looks pretty standard for compatibility with older PCs. My problems: ------------ #1: I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory). What should I do about this? Should I use some "graphics.h" or such? #2: I'll be doing heavy HDD I/O as the main task in this program will be file data analysing. I've read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing. Is this true? What would be the most efficient way? #3: I need a very light and very specific Window-GUI (by specific I mean I won't need many controls and they will need to be adapted to the program's needs), so I was thinking of making one of my own. Taking out the "complexity" issue which is being taking care of, the real doubt here is: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines? I point to that perhaps any other GUI already out there uses some other sophisticated techniques which would make them faster anyway... I should add that I'm not thinking of moveable/resizable windows, as it's more about n-criteria sorting flexgrids and checkable filelistboxes... #4: Some libraries already made objects from my project are currently working on VC++. Now, as you know, VC++ won't fit my 486 :), I've thought about "CommandLineTools.exe" (8,5MB) from borland but it seems to lack of some really important libraries such as "conio.h"!?!? (goodbye getch, kbhit :( ) So what I'm asking
Mariano Lopez-Gappa wrote:
I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory).
I don't see how you can target linux as well. IMO you should use DirectX for the fastest possible video. I don't think that asm is a good move, from a maintainability standpoint as much as anything, but I also believe that DX handles differences between video cards for you - you don't want to do that in asm. Even creating a DIBSection will give you direct memory access to bitmap bits, although running in 256 colour mode means you're using a palette, which is always more messy than 16 bit or higher.
Mariano Lopez-Gappa wrote:
read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing.
That's possible, are you reading binary data, or text. You should use the class that's optimised for the sort of data you want to read. Worry about speed as it becomes an issue, and do your own tests to see what works best.
Mariano Lopez-Gappa wrote:
Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines?
No. Using Win32 is as close to the machine as you need to get.
Mariano Lopez-Gappa wrote:
Which C++ distribution will fit best my needs, given all you've read so far?
The command line compiler that comes with VC.
Mariano Lopez-Gappa wrote:
What are the main incompatibilities I should be aware of between XP, Dos 16bit and Linux?
DOS means writing a text only program, or doing the graphics by hand. Linux will have it's own libraries for graphics. I don't see you targetting all three, without an abstraction that allows you to write three presentation layers.
Mariano Lopez-Gappa wrote:
While secondary to the main functionalities of the program, I will need to show BMPs, play WAVs, timing events and implementing sprites/masks
Windows will let you show BMPs, play WAVs and run a timer. Christian Graus - Microsoft MVP - C++
-
hi! I'm a college student but on spare time like programming, I've been programming since I was ten, and this summer I'm getting my hands on a big C++ programming project. I'm currently on the "planning stage" and need help on the following: First a few things you should know in order to help: --------------------------------------------------- -Most of the coding is to be done on a 486dx2 8MB RAM 800MB HDD notebook, which is able to run W95 and DOS. Graphic mode works. I haven't tried Linux, but I don't think it would be practical, as I need as much HDD I can get for project sample data. -My main goal is efficiency meaning speed (and results, though not relevant here) and compatibility with at least every Windows-DOS PC (allowing 640x480x256) and if possible Linux. -This program will NOT use MFC, but needs to be able to init graphic mode at 640x480x256. I want specifically this as it looks pretty standard for compatibility with older PCs. My problems: ------------ #1: I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory). What should I do about this? Should I use some "graphics.h" or such? #2: I'll be doing heavy HDD I/O as the main task in this program will be file data analysing. I've read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing. Is this true? What would be the most efficient way? #3: I need a very light and very specific Window-GUI (by specific I mean I won't need many controls and they will need to be adapted to the program's needs), so I was thinking of making one of my own. Taking out the "complexity" issue which is being taking care of, the real doubt here is: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines? I point to that perhaps any other GUI already out there uses some other sophisticated techniques which would make them faster anyway... I should add that I'm not thinking of moveable/resizable windows, as it's more about n-criteria sorting flexgrids and checkable filelistboxes... #4: Some libraries already made objects from my project are currently working on VC++. Now, as you know, VC++ won't fit my 486 :), I've thought about "CommandLineTools.exe" (8,5MB) from borland but it seems to lack of some really important libraries such as "conio.h"!?!? (goodbye getch, kbhit :( ) So what I'm asking
I think Borland Turbo C++ 3 should get the job done, but you will stay in 16-bit, which means a maximum of 640KB of RAM, out of which you will probably get 500KB. That is the main bottleneck. 1- You can use the SVGA modes. For 640x480x8, the mode is 0x101. There are lots of resources on the net for any graphics modes. Most PCs 486 dx2 will allow that mode (0x101). It actually depends on the Graphics Card RAM. You should have at least 1MB. However, any modern OS will not allow you to use these display modes. You may not use the graphics.h which comes with Turbo C. 2- Binary is faster. 3- About the GUI, you won't get anything. You will not even get basic I/O routines like cout, printf etc, or any GUI stuff like textout, outtextxy either. You will need to do them yourself. ASM may be used, but needed only for mouse-support, and to change the pallete (8-bit modes need to use palletes for bmps). If you are thinking about grids and listboxes, then it is a lot of work. I created such a library some years ago, it had editboxes, vector fonts, radio buttons, checkboxes, command buttons, keyboard, mouse support. It was hard work. And you will need to display the mouse cursor yourself also. 4- I have never used Linux, so I can't comment, but Borland Turbo C++ 3 or 3.1 should do. It has conio.h for getch, kbhit etc. 5- The 16-bit program will run well on a 486. But it may or may not run on Win2000, XP. 6- See (3) above. You might find such a library on the net. 7- For BMPs and Wavs, it is very cool for DOS programs to display pics and use the sound card. The bmp algorithm is easy to find on the net, but there is the limit of ram you can use. About wav files, find documentation for the sound card you are using, like Sound Blaster; Their docs are easy to find. Hope that helps a little. this is this.
-
I think Borland Turbo C++ 3 should get the job done, but you will stay in 16-bit, which means a maximum of 640KB of RAM, out of which you will probably get 500KB. That is the main bottleneck. 1- You can use the SVGA modes. For 640x480x8, the mode is 0x101. There are lots of resources on the net for any graphics modes. Most PCs 486 dx2 will allow that mode (0x101). It actually depends on the Graphics Card RAM. You should have at least 1MB. However, any modern OS will not allow you to use these display modes. You may not use the graphics.h which comes with Turbo C. 2- Binary is faster. 3- About the GUI, you won't get anything. You will not even get basic I/O routines like cout, printf etc, or any GUI stuff like textout, outtextxy either. You will need to do them yourself. ASM may be used, but needed only for mouse-support, and to change the pallete (8-bit modes need to use palletes for bmps). If you are thinking about grids and listboxes, then it is a lot of work. I created such a library some years ago, it had editboxes, vector fonts, radio buttons, checkboxes, command buttons, keyboard, mouse support. It was hard work. And you will need to display the mouse cursor yourself also. 4- I have never used Linux, so I can't comment, but Borland Turbo C++ 3 or 3.1 should do. It has conio.h for getch, kbhit etc. 5- The 16-bit program will run well on a 486. But it may or may not run on Win2000, XP. 6- See (3) above. You might find such a library on the net. 7- For BMPs and Wavs, it is very cool for DOS programs to display pics and use the sound card. The bmp algorithm is easy to find on the net, but there is the limit of ram you can use. About wav files, find documentation for the sound card you are using, like Sound Blaster; Their docs are easy to find. Hope that helps a little. this is this.
First of all thx for your reply and thx to the other 2 guys replies. All of you helped a lot. New questions have arised due to replies: #1: My knowledge of technical differences between 16-32-64 bits is little or none...but I'm definitely gonna need more than 640K lol. There's gotta be a way to bypass the 640K limit! I thought mallocating on C and "New-ing" on Pascal allowed use of extended memory... Well, if it just can't be done, I can work it out by not exceeding the limit while I use the 486...resigning compatibility with it, it's ok, it wasn't that big deal...nor was Linux compatibility. It seems I'm gonna need a 32-bit compiler (though I don't really know much what it means), perhaps this is what "BBC32" meaning was (32 bit). What compiler should I use given the new circumstances? Will it still run on the 486? #2: The graphic issue seems problematic, seems I'll have to make a first version working on the 486 and then the release one. So, given the first one is ok, what would be the better choice for graphic mode compatibility between W98-Me-NT-2000-XP? I should add that there's no way Ima use MFC nor DirectX. Thx in advance!! Mariano Lopez-Gappa