Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
QB64 Discussion / Re: Internal's c/c++ compiler
« Last post by mcalkins on May 12, 2013, 05:26:10 AM »
c++.exe and g++.exe are absolutely identical. You can verify this with a file comparison utility or a file hashing utility. If g.exe exists, it is also identical with these two.

I don't know what cpp.exe is for.

Use g++.exe if you can. This works for C++ source files, and for some C source files. If a source file is specifically C as opposed to C++, you can use gcc.exe instead. Some code will compile correctly as either C or C++, as there is a common subset between the two languages. Some C code will fail to compile as C++, or will compile, but will then behave differently. (It is possible to compile C and C++ source files separately, and then link the modules together.)

P.S. I think that the file extension is also involved in determining whether the source file is treated as C or C++.

Regards,
Michael
22
QB64 Discussion / Re: Internal's c/c++ compiler
« Last post by Billbo on May 12, 2013, 04:23:36 AM »
mcalkins,

Super thanks for the links, options, etc.

There one issue. The file name to use. From Galleon's post,
which you thankfully provided:

 qb64\internal\c\c_compiler\bin\gcc.exe is the main C compiler, gpp.exe is the C++ compiler

Now, you do not mention the gcc.exe, but you have g++ for his gcc. There are four(4) files
in the directory:

  cpp.exe
  c++.exe
  gpp.exe
  g++.exe

God forbid for me to say that you are wrong, but which of the two(2) files should I use,
or all four(4) and what's the difference? I know, eveyone says to research first, but you
don't find something like that in the help file.

Super Thanks, Again,

Bill
23
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by Galleon on May 12, 2013, 03:42:45 AM »
Here's a screenshot of the new _ICON command being used to full effect (alpha and separate icon for window icon vs program icon). I magnified the view so you can see the alpha effect a little more clearly.

What I intended to do was eventually provide a $ICON meta-command like...
$ICON: "qbicon32.png", "qbicon16.png"
At compile time it would use given images (including selecting from multiple if available, eg. in a .ico) and embed them in your executable as the executable file's icon and the default program icons at run-time. Most importantly, it would negate the need to have image decoders in your application simply to use an icon because the QB64 compiler would load, analyze and embed the images given appropriately for the given platform.

I've taken the liberty of reworking the current QB64 icon a tad whilst still keeping the layout of the original.

In QB64-SDL the QB64 icon was displayed by default until overwritten by _ICON. I've decided to remove this behaviour in QB64-GL. If you actually want the QB64 _ICON you can still get it by using _ICON without any arguments. Why do this? Because for a split-second the QB64 icon is visible until overwritten and this is undesirable for anyone using _ICON. The real solution to this scenario would be the proposed meta-command.
24
QB64 Discussion / Re: Internal's c/c++ compiler
« Last post by mcalkins on May 12, 2013, 03:10:25 AM »
http://www.qb64.net/forum/index.php?topic=10921.msg91756#msg91756

g++.exe is the compiler. It usually invokes the linker for you. ld.exe is the linker.

Some useful options for g++:
Code: [Select]
--help        help
-s        strip symbols
-g        include debugging info
-Wall        enable additional warnings
-o filename        specify output filename, example: -o hello.exe
-l filename        specify a library, example: -l gdi32 (A few libraries are automatically assumed.)
-c        compile, but do not link (useful for creating static libraries)
-O3        optimize for speed
-fno-strict-aliasing        disable optimization based on strict aliasing rule
-fno-strict-overflow        disable optimization based on strict signed integer overflow rule
-Wl,...        pass comma separated arguments to linker.
-Wl,-Map,filename        tell the linker to create a map file
-mconsole        create a console program
-mwindows        create a GUI program (changes the subsystem field, changes the entry point and main function, and automatically adds a few libraries)
For a complete list, see: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

Example:

delme.cpp:
Code: [Select]
#include <stdio.h>                     // declares printf, fgets, and stdin
#include <stdlib.h>                    // declares atoi

int main() {
 enum {SizeOfArray = 20};              // SizeOfArray is a constant. By using a symbolic constant, we would only have to change it here, instead of hunting down each literal constant.

 int a, b;                             // a and b are 32-bit signed integers (on this platform)
 char c[SizeOfArray];                  // c is a constant pointer to an array of 20 8-bit signed integers (on this platform)

 printf("\nEnter a number: ");         // the compiler changes \n to a line break character (CHR$(10))
 fgets(c, SizeOfArray, stdin);         // read up to 19 characters from stdin, and store in the array pointed to by c. (up to 19 characters from stdin + 1 null character, for a total of up to 20.)
 a = atoi(c);                          // convert the text in the array pointed to by c to an integer
 printf("\nEnter a number: ");
 fgets(c, SizeOfArray, stdin);
 b = atoi(c);
 printf("\nAdded: %i, Subtracted: %i\n", a + b, a - b);        // %i tells printf that it has an integer parameter
 return 0;                             // main returns an int. This becomes the process exit code.
}

From the command line, within your QB64 folder, either:
internal\c\bin\g++ -s -O3 -Wall -o delme.exe delme.cpp
or:
internal\c\c_compiler\bin\g++ -s -O3 -Wall -o delme.exe delme.cpp

depending on whether you have QB64 SDL or QB64 GL.

Regards,
Michael
25
QB64 Discussion / Re: Full-Motion-Video for QB64 (player and recorder libraries now released)
« Last post by MPSGA on May 12, 2013, 02:39:04 AM »
Quote from: Cyperium on May 12, 2013, 02:20:53 AM
There's no difference loading a file into memory and reading it, than to read it from disk. I think he was concerned about the memory usage over-all. If he has the ability or not is up to him though, but it's certainly possible.
Ah, I see. I guess loading one frame and then unloading it after showing it is the most reasonable method when it comes to low-memory applications.
26
QB64 Discussion / Re: Full-Motion-Video for QB64 (player and recorder libraries now released)
« Last post by Cyperium on May 12, 2013, 02:20:53 AM »
There's no difference loading a file into memory and reading it, than to read it from disk. I think he was concerned about the memory usage over-all. If he has the ability or not is up to him though, but it's certainly possible.
27
QB64 Discussion / Re: Full-Motion-Video for QB64 (player and recorder libraries now released)
« Last post by MPSGA on May 12, 2013, 02:08:05 AM »
Quote from: Jobert14 on January 30, 2013, 05:48:13 PM
Quote from: MPSGA on January 27, 2013, 08:30:58 AM
Does it use so little memory by design or by accident? :D

It uses that much memory because it only loads frames one by one straight from disk as I knew that its a bad idea to load all frames at once. The downside is that if the disk reads are not fast enough, the playback will suffer from pausing or stuttering.

I already knew that concept ever since I started doing FMV experiments in my QB45 days...Loading every uncompressed frame straight from disk as fast as possible using DOS interrupt calls. The biggest problem is that the video file is HUGE! As the 320x200 8-bit frames were uncompressed and loaded straight into video memory as any form of data compression was too slow. Add the size up with uncompressed 22050Hz 8-bit mono sound.
Is there a better way than just loading frames one by one? Or is it the best you know or the best QB64 can do?
28
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by DSMan195276 on May 11, 2013, 10:01:50 PM »
I think it'd be better to just have some way of specifying what image to get from the file in the code. But either way, figuring out a way to specify what image to load in code shouldn't be that complex to do, definitely not the biggest hurtle here. GIF's could also use the same support for accessing multiple images in them as well.

Converting that to C shouldn't be very hard (But, if Galleon can't do it, it would be a while before I'd be able to take a stab at this.). Seeing as BMP code was recently put into QB64, we could probably base the code off of that (or even just extend that code) to make it easier to get the stuff that has to go on with QB64 internally correct. The only thing that worries me a bit is the compression (BMP's have the same issue, I don't know if QB64 currently supports compressed BMP's). Are you sure that the compressed byte will always be set to zero? If that's the case then that will definitely simplify things, if not then adding support for the compression schemes would be needed.

Assuming the ICON file is embedded, then depending on what support we give to this idea memory leaks will still be a present issue. I know what you mean by memory leaks can't come from storing something in a file, but to display the image you unavoidably have to read it into memory. I'd much rather add support for being able to embed any type of image you want instead of just allowing embedding icons and then probably added another separate command for everything else later on (Though, if icon's have to be embedded in a bit different manner, then that's a different story).

Since _ICON takes an image handle and currently uses an image to display it, that image does need to be freed at some point. _ICON "filename" doesn't allow you to free it, creating a memory leak. What it should do in this case to allow you to avoid that memory leak is debatable, but currently there would be no way around that issue. It's really not that big of a deal though, as long as you just make sure you get a copy of the handle via _LOADIMAGE() before using _ICON then you can always free it when needed.

Matt
29
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by Clippy on May 11, 2013, 09:35:29 PM »
Icon structures are not hard to do. I have already done them with multiple images. All that has to be done is convert it to C. I've used them with QB64 without using _LOADIMAGE. I even converted them to bitmaps so that _ICON could use them.

http://qb64.net/wiki/index.php?title=Icons_and_Cursors

The biggest problem would be specifying the one you want to use. That's why I think the IDE could be useful to set it up. Perhaps a preview? If no icon number is given, it would default to the first one.

If the image is embedded then any "leaks" could be avoided as the program would have direct access much like the QB64 icon already hidden in the EXE. Memory leaks would not be created by the file itself so put the blame somewhere else.  ;)

I'd like to see the ability to add other resources to programs too. Michael could help.

30
Beginner's Help / Re: Just For Kids
« Last post by OlDosLover on May 11, 2013, 09:04:21 PM »
Hi all,
    I am still working on this project. I am replacing the Animal sounds program with a jigsaw program. I have been discussing the openness of this project on the following site:
http://www.trig.com/group/290
OlDosLover.
Pages: 1 2 [3] 4 5 ... 10