I am making a login page for a game , That uses outextxy() for output;
So I would like to have the input at a specific desired location ( at specific coordinates )
[using cin doesn't help it stills input from the top of the program ],
Is there any inbuilt function for this ??
I have even tried using gotoxy() ..but didn't work ,
gotoxy(320,15);
cin>>a;
It will be really helpful if u can explain or give a link to explain( if it requires good knowledge , cause i am still a beginner )
You are reading from cin just as you are used to. But it is you that should take care to display what is displayed. C++ won't do that for you. For instance if you are entering a string after entering a character, you have to display it in the desired location. Things get even messier once you start dealing with correction in the input(i.e. pressing backspace). I have implemented several games using graphics.h myself and remember dealing with all this tweaks was hell.
My proposal is that you try to use a more advance graphics library. My personal choice is usually opengl. For it you can find a lot of helper libraries for instance wxWidgets.
graphics.h is part of the ancient DOS library called BGI, delivered with old Borland compilers only. Borland stopped supporting this 15 years ago. In fact Borland doesn't even make compilers any longer. And no other compiler has ever supported it. Also, Windows no longer support 16-bit DOS programs so you can't even run BGI programs on modern computers.
Don't use graphics.h.
Better alternatives are OS-dependent. In Windows you should use the console functions API and in Linux there is a library called ncurses. Though of course, this would mean that you would have to upgrade to 32 bit computer...
oh i figured it out... it was stupidity on my part .. referred the help file and came to know that gotoxy has some maximum arguments ( but I still don't understand the value of arguements )
Courtesy : Lundin
Related
I would like to write a console app with text UI in D. I looked at curses, but it seems that it works only on unix. Are there any cross-patform alternatives?
My terminal.d could be used as a foundation for a TUI library.
https://github.com/adamdruppe/arsd/blob/master/terminal.d
It has no required dependencies, so you can simply download that one file and start building with dmd yourfile.d terminal.d. Here's an example program getting input: http://arsdnet.net/dcode/book/chapter_12/07/input.d
You can also use terminal.moveTo(x, y); terminal.color(Color.green, Color.black); terminal.writef("something"); terminal.flush(); and such to move and draw.
Look for version(Demo) in terminal.d itself for a main which handles all kinds of input events, including mouse events.
While terminal.d mostly offers lower-level functions (its main high level function is terminal.getline, great for line based apps but not TUIs), it should give all the foundation needed to write a little text widget library.
and I think someone might have done that once but I don't recall where.
terminal.d works on Windows and Posix systems, for the most common terminals like xterm. ncurses is more comprehensive and probably has fewer bugs on more obscure targets but terminal.d, being a single file, is easier to build.
That was true long ago. However, ncurses is known to work nicely on Windows as well. The easiest way to build it on Windows is inside the MSYS2 shell. There is really no other cross-platform alternative to Curses (find out why they named the project "curses" and you will find why there is no good alternative).
I have a lot of simple C++ programs that I've written in XCode, using OpenGL and Glut to visualise scientific data. It works very well, but there is one minor annoyance: every time I run one of the binaries from outside of XCode, it opens a Terminal window. This means I get a crusty build-up of Terminal windows that has to be cleaned up after use.
Is there a way to prevent this from happening? I'm hoping for a quick solution to a very minor problem, so anything that requires me to learn Objective C or some fancy GUI creation tool isn't what I want. I just want to know if there's a way to compile my existing C++ Glut apps in such a way that the terminal window won't appear when you click on the icon.
Sort of... Basically, you need some kind of OS X wrapper to contain the binary. You can do this with Automator or AppleScript or with a tool like DropScript, which is designed to encapsulate unix binaries.
Otherwise, the solution for this would be to create a minimal Objective-C program and then she'll out the unix binary from within it, so that when it terminates it doesn't leave any residue.
I am using Windows 7 and developing a chat-like application with Visual Studio 2010. I am looking for an EASY way of capturing audio from a microphone (or rather, from the default recording device), collect the buffer from said input, and send it over a socket. I've seen DirectX solutions recommended, but from my research that is quite the opposite of simple. 5000 lines of sample code for a simple capture/save file program? That simply doesn't work for me (and yes, that was an official sample provided with the SDK).
Anyway, I don't need it to be cross-platform, and I would really prefer something that already comes with Windows, though I don't mind installing a library as long as it doesn't take longer than writing the hardware drivers from scratch to figure it out (exaggeration). I've heard of this waveInOpen function, but oddly enough I cannot find any demos on how to use it. If anyone has an idea or a link to some sample code, I would greatly appreciate it. Thanks everyone for your time!
P.S. I can figure out the networking part myself. I just need access to the raw audio data buffer.
If you're doing the sockets yourself try checking out:
http://www.techmind.org/wave/
http://www.bcbjournal.com/articles/vol2/9810/Low-level_wave_audio__part_3.htm
http://www.relisoft.com/freeware/recorder.html
I enjoyed all of them but the last one, but then again, you might find it far more helpful.
Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.
I'm having problems opening directly TurboC++ compiler(dos version) on Windows X.
if I click on the TurboC++ icon through windows GUI it opens for a sec(a blank dos screen)
and shuts down.
so i have to access it through the command line i.e.,
cmd (enter)
c:\tc\bin (enter)
tc.exe
This way TurboC++ opens and I'm able to program and everything..
Why do I have to always start tc.exe through the command line? Why can't I start it through Windows XP?
Also, after starting tc.exe through the command line, I am unable to execute any graphics program through it.
I write a simple code for creating a circle using predefined functions..
when i compile and run the program tc.exe exits and returns back to the command prompt.
Why does this happen?Is there a solution?
I have also tried using DosBox to run TurboC++. it closes on executing the graphics program.
ps: this problem has occurred to only me and my friend.....
all PCs in our college have Windows XP or Vista installed and they have no problems.
im using initgraph(); function for initialising graphics drivers(using autodetect) and graphic mode.i have given the proper address for bgi files. and the folder contains the file required (EGAVGA.bgi). this program works fine in our college.does this have something to do about my graphics card(nvidia 9400 1gb)?
Graphics in the 80s were a completely different world than today - directly accessing hardware, often using undocumented features to optimize performance. Drivers didn't exist in DOS. Each program had to write their own hardware layer (hence why under DOS, you had to configure the video and soundcard for every single game separately. The fact that we can run any software from the 80s is a testament to the backwards compatibility work done by Microsoft.
You might have some luck running it on VirtualPC, VMWare or VirtualBox. All of them offer a free version, and if you can find and old copy of DOS 6.22 lying around, you might be good to go. Otherwise, you'll likely be stuck finding a physical 486 running Windows 3.11, and working on that. Depending on what deals your college has with Microsoft, they should be able to get a copy of DOS 6.22 for free - it's still offered for download on MSDN. Although, if you're still using TurboC++, they have not likely signed up for anything with MS. You can also try FreeDOS.
Right click on the TC icon and pick Properties. Go to the Compatibility tab. Play with the settings found there. If that doesn't help, ask your teacher how to use a 25 year old program on a modern computer.
How are you doing graphics? If you're using int 10h (or equivalent) to change the mode, that should work fine as it stands. If you're using BGI, make sure the program's working folder contains the BGI files that come with Turbo C++ -- for more details on initializing BGI, look up initgraph in the help.
Even modern PCs with modern graphics cards seem to have enough legacy support for the BGI code to work, though it seems like the program always runs fullscreen once in graphics mode, rather than in a window.
I don't know why Turbo C++ might not start from the GUI unfortunately. I've used Borland C++ just now to refresh my memory about the BGI stuff, and it worked OK.
Use visualc++ express instead. Its free and equipped with c++11.
for opening problem you can use a .bat file for opening Turbo C++
as follows:
open notepad and type the address of TC.exe and name of exe file like
D:\bhanu\TurboC++\TC.exe
and save it as TC.bat instead of TC.txt
and now double click it to run TC.
For graphics you first copy EGAVGA.BGI file from bgi folder to bin and then in the Turbo c++ open options->linker->library
and mark 'X' on bottom two libraries and un-mark all other libraries.