Libraries for QuArK.

[pathetic_programmer]

While looking through the forums I read what QuArK 7 was going to start using in the future and thought I'd add my two cents in.

Lua:  Lua is a very fast scripting language that can easily be embedded into the core of QuArK.  There are a large number of people that can write Lua as it is used for writing addons in World of Warcraft.  The license is lax too, it's under the MIT license. http://www.lua.org/license.html

Allegro: Allegro is also really easy to add and use.  Many aspects of Allegro could be very useful for QuArK.  Keyboard, mouse and joystick input.  Window creation, 2D, 3D drawing, (the 3D drawing is quite basic; however it does use OpenGL).  File loading and saving.  Even sound, but I don't think that's fully needed here...... At least not yet. http://alleg.sourceforge.net/

I think those two could definitely speed up the production of QuArK 7.  Both of those libraries have lax licenses, (Allegro is giftware, you can use it and not say that you used it at all, if you're a jerk).  They're also Cross-Platform as well.

Up until 5.0, Allegro didn't have any real 3D graphics capabilities.  They wanted to avoid it since there were so many other 3D libraries out there.  If a fast one is needed, Irrlicht would be the way to go.  Reading a good deal of feedback on the differences between Irrlicht and Ogre3D, Irrlicht is really easy to get stuff on the screen; Ogre3D is a fuller engine.  Ogre3D is also a fairly complex beast to get working and a large amount of C++ knowledge is needed to get it working.

If QuArK is going to try and become cross-platform,(and possibly use the libraries above), then I'm going to try and help out if and when I can.  I'm not a very reliable person right now though, I'm trying to buy a house and have a bad case of writer's block as well, (my name may be more apparent now).  I'm hoping joining something I have no control over might help me get out of the block so I can work on other things.

Also, CODE::BLOCKS, Code::Blocks, cOdE::bLoCkS.   Code::Blocks is a free, open sourced, cross-platformed (did I mention I love cross-platform programs/libraries?) IDE that can be used on Windows, Linux and Macs.  I personally believe that if everyone uses the same IDE, then it could really help people stay on the same page since there's no need to convert projects between IDEs/OSs.  I won't use Visual Studio, free version or not.  And every project I've tried to convert from VS to CB has given me a ton of problems.

[DanielPharos]

Lua: Currently, our prime choice is Python. I'm not familiar with Lua, but from what I can tell, Python is more powerful out-of-the-box. There will be need for some massively large, complicated mathematical calculations, and according to 'the internet', Python is more suitable for that than Lua is. Also, Python is more wide-spread, thus a larger potential pool of contributors. Plus, several other editors in the field use Python (including QuArK 6), so code-sharing would be easier with Python.

Allegro: Am I right that it's only useful for the 3D viewports etc., and not for the main application windows? I'll keep it in mind!

The plan for QuArK 7 is to be completely cross-platform: the only platform restrictions in QuArK's own code will be:
1) The need for a C++ compiler
2) Whatever Python wants
3) Whatever Boost wants
4) Whatever Qt wants, although this module can be replaced

All the platform-dependant code will remain in the C++ part of QuArK.

Personally, I use Visual Studio on Windows, but there will (obviously) be no compiler-specific code used. You're free to set-up a Code::Blocks project with QuArK 7's code. I don't see a need to constantly convert between IDEs/OSs... (And, the majority of QuArK will be in Python; the C++-code will only be a small part, that should become pretty static very quickly.)

[pathetic_programmer]

Lua: Currently, our prime choice is Python. I'm not familiar with Lua, but from what I can tell, Python is more powerful out-of-the-box. There will be need for some massively large, complicated mathematical calculations, and according to 'the internet', Python is more suitable for that than Lua is. Also, Python is more wide-spread, thus a larger potential pool of contributors. Plus, several other editors in the field use Python (including QuArK 6), so code-sharing would be easier with Python.

I'll take your word for it.  I've never really used Python and can't give a valid argument either way.  With what I'm building, I'm looking more for speed than power.  I plan on using C/C++ to do the dirty work and the Lua will be more of a way to get script into the C/C++ engine.

Allegro: Am I right that it's only useful for the 3D viewports etc., and not for the main application windows? I'll keep it in mind!

No, it's basically a library that can do a little bit of everything, except networking for now.  Here's a list of their API functions and their addons:

    * Configuration files
    * Display routines
    * Events
    * File I/O
    * Filesystem
    * Fixed point math
    * Graphics routines
    * Joystick routines
    * Keyboard routines
    * Memory management
    * Mouse routines
    * Path structures
    * State
    * System routines
    * Threads
    * Time
    * Timer
    * Transformations
    * UTF-8 string routines
    * Miscellaneous
    * Platform-specific
    * Direct3D integration
    * OpenGL integration

Addons

    * Audio addon
    * Audio codecs
    * Color addon
    * Font addons
    * Image I/O addon
    * Memfile addon
    * Native dialogs addon
    * PhysicsFS addon
    * Primitives addon

It is a very quick way to start building games.

The plan for QuArK 7 is to be completely cross-platform: the only platform restrictions in QuArK's own code will be:
1) The need for a C++ compiler
2) Whatever Python wants
3) Whatever Boost wants
4) Whatever Qt wants, although this module can be replaced

All the platform-dependant code will remain in the C++ part of QuArK.

Personally, I use Visual Studio on Windows, but there will (obviously) be no compiler-specific code used. You're free to set-up a Code::Blocks project with QuArK 7's code. I don't see a need to constantly convert between IDEs/OSs... (And, the majority of QuArK will be in Python; the C++-code will only be a small part, that should become pretty static very quickly.)

That's what I was talking about, the projects.  VS and CB use two different projects.  GCC is the GNU compiler and it can run on both Windows and Linux.

I forgot which thread, but I saw that y'all were going to use some debugging and profiling.  Quick suggestion, choose one or the other before any major work starts on 7.
http://www.google.com/#hl=en&cp=8&gs_id=1h&xhr=t&q=debug+vs+release&fp=26342f6f6a27a32b

[DanielPharos]

Allegro: Am I right that it's only useful for the 3D viewports etc., and not for the main application windows? I'll keep it in mind!

No, it's basically a library that can do a little bit of everything, except networking for now.  Here's a list of their API functions and their addons:
...
It is a very quick way to start building games.

Ah, okay, so it could replace Qt. Okay, I'll check it out then!

The plan for QuArK 7 is to be completely cross-platform: the only platform restrictions in QuArK's own code will be:
1) The need for a C++ compiler
2) Whatever Python wants
3) Whatever Boost wants
4) Whatever Qt wants, although this module can be replaced

All the platform-dependant code will remain in the C++ part of QuArK.

Personally, I use Visual Studio on Windows, but there will (obviously) be no compiler-specific code used. You're free to set-up a Code::Blocks project with QuArK 7's code. I don't see a need to constantly convert between IDEs/OSs... (And, the majority of QuArK will be in Python; the C++-code will only be a small part, that should become pretty static very quickly.)

That's what I was talking about, the projects.  VS and CB use two different projects.  GCC is the GNU compiler and it can run on both Windows and Linux.

I forgot which thread, but I saw that y'all were going to use some debugging and profiling.  Quick suggestion, choose one or the other before any major work starts on 7.
http://www.google.com/#hl=en&cp=8&gs_id=1h&xhr=t&q=debug+vs+release&fp=26342f6f6a27a32b

Choose one what? 'debug' or 'release' build? Well, obviously, we're going to use both! If you mean which IDE, that's completely up to the programmer. I'll be using Visual Studio on Windows, and simple Emacs/VI-style programs on *nix and Mac (Windows is my main platform). The current test-codebase compiles fine on all three, so it works fine with the MSVC compiler and GCC. I'm sure MinGW, Intel C++ or Borland C++ would compile the code fine too (some tweaking may be required).

[pathetic_programmer]

Choose one what? 'debug' or 'release' build? Well, obviously, we're going to use both! If you mean which IDE, that's completely up to the programmer. I'll be using Visual Studio on Windows, and simple Emacs/VI-style programs on *nix and Mac (Windows is my main platform). The current test-codebase compiles fine on all three, so it works fine with the MSVC compiler and GCC. I'm sure MinGW, Intel C++ or Borland C++ would compile the code fine too (some tweaking may be required).

Well, I didn't really give a reason why you should follow any of the links, so I guess that's my fault.  If you read some of the first Google results for "Release vs. Debug" then you'll find out that they're practically two totally different programs after they're built.  Starting your program off using Debug and switching to Release can cause little unforeseen flaws to appear.  Uninitialized variables get initialized in Debug mode but they stay uninitialized in Release mode causing undefined results, (which I like to call: Headaches).  Like I said, best to choose one or the other.

I don't really use the debugging utilities that come with my IDE, or really like debuggers in general.  How do I debug?  Simple, I use a simple function that writes either to the STDOUT or to a log file.  If I recall correctly, I use:
#define d printf("\nLINE: %d, FILE: %s", __LINE__, __FILE__);
I don't have any of my programs handy to look at it right now.   After I have that declared, I put a d at the end of every line.  Should I need to disable it, I place a // before the printf function to make it a comment line.  This can cause problems if I have it after an if, case, for or do statement....... or anything like that.  Putting it into {} helps though.  Does it slow it down?  Sure does, but then again, when I'm debugging I want it to be slow.  Should the need to watch a variable arise, I simply redefine the d statement and append the variable that I want to watch.

[DanielPharos]

I don't know how you've been bitten by this in the past, but switching between Debug and Release build is the industry standard! I have no plans to do anything else. Debug builds do NOT initialize variables; they might initialize them with rubbish (DirectX does this with some buffers in Debug mode), but that's only to make improper use show up more clearly. Switching between Debug and Release can indeed cause very subtle flaws to appear, but that means you've got a bug in your program: I'd rather have the bugs show so I can fix them! By the way, your way introduces these subtle bug too, so I don't see why your way would be better?

(With debugging tools I also mean code analyzers and tools like valgrind, and some Windows-tools like 'Application Verifier'.)

Of course, if you develop purely in one of the two builds, that's fine! Don't forget: the C++-code is only a small part, that will be (mostly) finished quite early on. Most of the work will be the Python code.

[pathetic_programmer]

One more for the road:

Processes and IPC

• launching and stopping processes
• process synchronization
• shared memory

That might be good for launching other programs, like QuArK 6.

[DanielPharos]

Boost: http://www.boost.org/doc/libs/1_48_0/doc/html/interprocess.html
So, apart from the "launching and stopping processes", which is quite simply to do on most OSes, I don't think that library adds much, especially since there's only going to be a minimal amount of IPC. But, if I need it, I'll use it, thanks!

[pathetic_programmer]

Boost: http://www.boost.org/doc/libs/1_48_0/doc/html/interprocess.html
So, apart from the "launching and stopping processes", which is quite simply to do on most OSes, I don't think that library adds much, especially since there's only going to be a minimal amount of IPC. But, if I need it, I'll use it, thanks!

No, it does more than that, I was just being lazy and putting something in to make you look at the site.  I didn't know Boost could do that; I haven't messed with it that much at all just yet.  The last time I tried to use Boost was about 6 years ago and the documentation wasn't very helpful to me, so I moved to other libraries.

After looking at Boost's features again, there's not really much that Poco can improve on for QuArK, but if anyone is interested in the features list:

Design & Implementation

• Written in modern, standard ANSI C++, using the C++ Standard Library. Modular design, very few external dependencies, builds out-of-the-box. Good mix of "classic" object-oriented design with modern C++. Clean, easy-to-understand code (we frequently get compliments on that), consistent coding style, comprehensive test suite.

Platforms

• Desktop/Server: Windows, Linux, Mac OS X, Solaris, HP-UX, AIX
• Embedded: Windows Embedded CE, Embedded Linux (uClibc or glibc), iOS, QNX, VxWorks, Android
• Minimum system requirements: 75 MHz ARM9, 8 MB RAM (Embedded Linux).

License

• Boost Software License 1.0

Core Features

• Any and DynamicAny classes for dynamic typing
• cache framework
• date and time
• events (signal/slot mechanism) and notifications framework
• regular expressions (based on PCRE)
• shared libraries and class loading
• smart pointers and memory management (buffer, pool)
• string formatting and string utilities
• tuples

Compression

• stream classes for zlib-based compression/decompression
• ZIP file creation and extraction

Cryptography

• cryptographic hashes
• X509 certificate handling
• symmetric and RSA ciphers
• streams for encryption and decryption
• based on OpenSSL

Database

• unified access to different SQL databases (SQLite, MySQL, ODBC)
• automatic data type mappings
• collections support (std::vector, std::set, std::map, etc.)
• record sets and tuples
• session pooling

Filesystem

• platform-independent path construction and manipulation
• directory listing
• globbing
• file attributes

Logging

• extensible logging framework with pluggable log channels and message formatters
• console logging, log files, syslog, remote syslog, Windows event log service

Multithreading

• thread and thread synchronization classes
• thread pool
• work queues
• active objects and activities
• task management
• timers

Network

• stream, datagram, multicast, server and raw sockets
• TCP Server framework (multithreaded)
• reactor server framework
• HTTP(S) client and server framework
• C++ server page compiler for embedding C++ code into HTML pages
• FTP client
• SMTP and POP3 client for sending and receiving email
• URI and UUID handling
• HTML forms processing
• MIME multipart messages
• SSL/TLS support based on OpenSSL

Processes and IPC

• launching and stopping processes
• process synchronization
• shared memory

Streams

• Base64 and HexBinary encoding/decoding
• compression (zlib)
• line ending conversion
• memory streams
• text encoding conversions
• URI stream opener

Text Encodings

• UTF-8 and Unicode handling
• text encodings and conversions
• character classifications

Utility Classes

• frameworks for command-line and server applications
• command-line options handling
• configuration file parsing
• unix daemons and windows services

XML

• fast XML parsing based on Expat
• SAX2 (Simple API for XML, version 2) parser
• DOM (Document Object Model, Level 1-3) parser
• XML writer

Except the underlined one, QuArK needs to be a DAEMON/SERVICE!!!