Jump to content

  • Log In with Google      Sign In   
  • Create Account


Bregma

Member Since 09 Dec 2005
Offline Last Active Today, 07:25 PM

#4997538 linux ncurses

Posted by Bregma on 05 November 2012 - 06:01 AM

so the kernel has console fuctions like, setconsolecursorposition, etc?

The kernel does not support concepts like consoles or cursor positions, at least not directly.

The way it works in a POSIX system like Linux is a display (whether it's a physical terminal connected over an RS-232C serial port or a virtual terminal rendered on a video card, what Windows parlance calls a 'console') is represented by a special file called a 'device,' and more particularly a 'character special device.' You open the device, read from it, write to it, close it, and sometimes perform out-of-band control functions on it (the ioctl() system call).

The specifics of which device you use and what control codes you send vary from target device to target device (and OS to OS, but assuming you're using a recent Linux kernel, you're probably targeting a /dev/tty* device).

There are libraries (man termcap) that help hide some of the device-specific peculiarities. You can also read the source of the built-in TTY driver in the kernel itself if you want to do fun things with the 'system console'. Read the manual on ioctl() for some addition hints, and hardware manuals for the various hardware or emulated hardware of a terminal window.


#4997362 How were Commodore 64 games developed?

Posted by Bregma on 04 November 2012 - 06:54 PM

I mean just like how you can just start the C64 without anything, and just write basic code and compile it without any compiling software, could you do the same exact thing with assembly, just go write some assembly code without anything and assemble same, same exact thing or did you have to Have some assembling software?

You would either use a macro assembler to convert your assembly code into a binary executable (which you could later LOAD *,8 and RUN), or hand-translate your assembly code into machine code and use the built-in BASIC interpreter to POKE the machine language into memory and execute it.

The C64 used a BASIC interpreter as its "shell". It did not have a line-by-line assembler as its "shell".


#4996465 Manual construction and destruction

Posted by Bregma on 02 November 2012 - 02:42 AM

When working with strings, I use char. With data, unsigned char. The reason is for safety while using the >> operator.
With char, it will carry the sign bit, which is rarely desirable when working with raw binary data.

Minor correction: with char it may or may not carry the sign bit, depending on the implementation. With signed char or unsigned char you know what will happen.

Also, the effect of std::operator>>(std::ostream&, char*) is different from std::operator>>(ostream& unsigned char*).


#4996195 Manual construction and destruction

Posted by Bregma on 01 November 2012 - 08:30 AM

How am I supposed to free the raw memory? Just delete[]?

If you allocate with ::operator new(), you have to deallocate with ::operator delete().


#4993132 Favorite little known or underused C++ features

Posted by Bregma on 23 October 2012 - 10:24 AM

Lambdas have suddenly (well, relatively speaking, given the glacial pace of standards development) made <algorithm> incredibly useful. I like lambdas + <algorithm>. The <random> library is a gollysend: generative environments that used to take hundreds of lines of code can be condensed down to a few dozen. std::function and std::bind working together make decoupling clear and maintainable. Uniform initialization is wonderful. Ya know, C++11 is just chock full of really, really useful stuff.


#4991860 Is it acceptable to call a destructor?

Posted by Bregma on 19 October 2012 - 12:32 PM

I would argue Brother Bob's way is most efficient and clean, and has the most elegant and clean syntax. Then again, I'm used to reading C++.

Laerning how to use the standard library (std::remove_if(), std::vertex()) and the language features (lambdas, auto type deduction) is the boss fight that will unlock the next level.


#4991824 accessing data from other .cpp files

Posted by Bregma on 19 October 2012 - 10:55 AM

Better yet, put the extern declaration in a header, and include that header in both .cpp files. That way, if either the declaration (in the header) or the definition (in game.cpp) gets changed bit the other does not, you get a compile failure instead of a mysterious runtime failure.

Also, putting shared variable declarations in header files documents them as being shared between .cpp files.


#4991643 Linux development

Posted by Bregma on 18 October 2012 - 08:28 PM

The line

LIBS = -lglut
should probably be
LIBS = -lglut -lGLU

Give that a try.

Linking libGLU will not be sufficient. You have to link -lGL to pick up the OpenGL library.

LIBS = -lglut -lGLU -lGL


#4991621 Good C++11 resources for advanced programmer

Posted by Bregma on 18 October 2012 - 07:33 PM

I'd strongly recommend, for your level of knowledge and what you're asking, "The C++ Programming Language" by Bjarne Stroustrup. It does not (yet) address C++11 features, but most of what you listed is not C++ but just the basic language as it's been since about 1992. There is no better reference for the fundamental language, and he writes clearly and concisely and covers almost everything you mentioned, including the reasoning behind language features and idioms.


#4991618 Linux development

Posted by Bregma on 18 October 2012 - 07:27 PM

You have added the header search path so the preprocessor can find the OpenGL header files.

You also have to add the OpenGL shared libraries for the linker to resolve those symbols. I don't know how to do it in your IDE, but it's gping to be something like "-lGL" added to the linker command line. This will pick up the library /usr/lib/libGL.so, which is probably a symbolic link to the real OpenGL library (for example, /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 on my system).

Look around for the linker settings and try adding that.


#4991128 Destructor vs Cleanup()

Posted by Bregma on 17 October 2012 - 08:30 AM


Why shouldn't one use exceptions in C++?

They can carry some very subtle, complicated costs and require some extra thinking when designing algorithms and classes. For games I don't really think they're worth said cost; in most cases using error codes can work equally well and can 're-enable' more dangerous (but speedier) class architectures. The latter is why I bring things up-- the C++ spec says the compiler will walk up the call stack, invoking destructors on everything until it finds an appropriate catch block. If you don't release any resources in the destructor, congratulations! You've just created a pretty massive, totally unfixable memory leak.

The cost of designing using object-oriented techniques, including exceptions, is no greater than procedural techniques and propagating error codes, unless and except if you are more familiar with one or the other. This is not a technical issue, but a personal or social issue.

It is easier to leak resources using procedural programming in which you need to handle releases nonlocally as you manually unwind the stack than it is using OO techniques in which the purpose of the destructor is to release resources. Sure, you can write bad code using any paradigm. You are less likely to write that particular kind of bad code using OO than procedural.

The third argument for using manual stack unwinding and error code propagation vs. exceptions is that you can write faster, simpler code with the manual method, because you just skip the error checks and cleanup code. You see a lot of that kind of code thrown up as examples of why exceptions are undesirable. I find it unconvincing.

The only really legitimate argument I've heard against using clean OO design with exceptions is that they're not supported by some runtimes. Now that seems fair to me, although the fact that they've been supported by C++ longer than most of the posters on these forums have been alive makes it seem to me that the vendor's decision on that front has been politically motivated.


#4990953 I caught an exception! Yay! Now what?

Posted by Bregma on 16 October 2012 - 06:41 PM

I'm not sure this really helps you, but Visual C++ allows you to set it to break on the line throwing any exception deriving from std::exception (as well as as lots of windows-specific exceptions).

Maybe gdb has something similar?

(gdb) catch throw

Yeah, sounds stupid. Works.


#4990941 Looking for a good keyboard synth program

Posted by Bregma on 16 October 2012 - 06:10 PM

You could start with Ubuntu Studio -- an entire distro build around making music, complete with kernel tweaked for realtime throughput.

I use regular Ubuntu with Rosegarden for a DAW and have several synths plugged in, and a virtual patch bay (JackRack) so my MIDI controller can be routed through the sequencer to any of them. It just works.


#4990712 How do I do OpenGL texture blitting

Posted by Bregma on 16 October 2012 - 07:41 AM

The version of the OpenGL API that is shipped with the Microsoft SDK is frozen at version 1.2 -- it's arms are too short for its great big head.

You need to use an extension wrangler, like glew or glee, to use something more recent than you're great-grandfather's OpenGL on Microsoft Windows.


#4990679 C++ Compiler and IDE

Posted by Bregma on 16 October 2012 - 05:16 AM

GCC isn't natively on Windows but the MinGW project is a port (among other things) of GCC.

I think you mean "the native port of GCC for Microsoft Windows is called MinGW". GCC isn't "for" any particular target, I used it on VAX/VMS and Atari TOS long before Linux, Mac OS X, or Microsoft Windows came along. The only time it's non-native is when it's a cross compiler -- and MinGW is actually available on Linux for building Windows apps with, if yuo're in to pain.




PARTNERS