News:
QB64 has been successfully ported to Google Android
http://www.qb64.net/forum/index.php?topic=10919.msg91805#msg91805
Recent Posts
11
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by DSMan195276 on May 12, 2013, 10:01:49 AM »I don't know specifically how Michael went around it. The way I'm thinking of doing it is simple but probably wouldn't be attached as Windows resource files (Which may be a good thing, since doing it that way wouldn't be amazingly cross-platform).
This program is very simple, but it'll take any file you want and convert it into a version which you can store in a C/C++ program. There are a few other things which could be done, and a few other modifications that could be made to the C/C++ depending on how it's implemented, but really this is nice and simple.
Matt
This program is very simple, but it'll take any file you want and convert it into a version which you can store in a C/C++ program. There are a few other things which could be done, and a few other modifications that could be made to the C/C++ depending on how it's implemented, but really this is nice and simple.
Code: [Select]
OPEN command$ for BINARY as #1
OPEN "output.c" for output as #2
print #2, "char file_array[] = {"
DIM c as _unsigned _BYTE
DO
get #1, , c
if flag <> 0 then print #2, ", "; else flag = -1
print #2, "0x"; hex$(c);
count = count + 1
if count = 20 then
count = 0
print #2, ""
end if
loop until eof(1)
print #2, "};";
close #1
Matt
12
QB64 Discussion / Re: Full-Motion-Video for QB64 (player and recorder libraries now released)
« Last post by MPSGA on May 12, 2013, 09:48:41 AM »Quote from: Jobert14 on May 12, 2013, 05:47:07 AM
Actually, loading all frames into memory and displaying each frame one by one is faster than reading from disk and decompressing the frame data. However, its obviously stupid to use that method. I mean, who makes a video player that consumes 80% of your system's memory?Yeah, it's logical.
The only problem this MVF video format suffers from is 'sound gapping' because it needs to read a lot of frame data from the disk due to its poor frame compression ratio compared to other video formats such as DivX, H.263, and MPEG. The gapping happens when the program that plays the video can't read data from the disk fast enough to achieve a nearly perfect 30FPS frame rate. The problem could be due to the OS or the disk cache.
But when it comes to audio, it should be smaller than all the frames together, so wouldn't it be somewhat smart (to my logic) to preload the audio and then load the images with audio playing? I know it can desync but isn't there techniques to sync frames to audio?
Of course, with the rather small image size of your video format it doesn't make a big problem, I think.
13
QB64 Discussion / Re: Help with Physics Simulator
« Last post by SkyCharger001 on May 12, 2013, 09:14:27 AM »that, or you make the active buffer iteration dependent. (which only requires one loop and thus should be faster)
even iterations: buffer A modifies buffer B.
odd iterations: buffer B modifies buffer A.
even iterations: buffer A modifies buffer B.
odd iterations: buffer B modifies buffer A.
14
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by Clippy on May 12, 2013, 09:08:40 AM »Well, Galleon is almost begging for somebody to add this functionality, now all we need is somebody to add it!
Several years ago, I came up with the idea and Michael Calkins finally came up with a way to do it. He even came up with a way to extract images from other EXE files. I don't care what kind of image you want to use, it can be done and it can be done correctly in Windows and whatever other OS could use it.
Now all we need is somebody to do it! You can bet that I would do it if I could! So who wants to do it?
Several years ago, I came up with the idea and Michael Calkins finally came up with a way to do it. He even came up with a way to extract images from other EXE files. I don't care what kind of image you want to use, it can be done and it can be done correctly in Windows and whatever other OS could use it.
Now all we need is somebody to do it! You can bet that I would do it if I could! So who wants to do it?
15
QB64 Discussion / Re: Help with Physics Simulator
« Last post by Cyperium on May 12, 2013, 08:04:51 AM »True, you have to do all calculations for each particle in one loop, then change the particles in another, since the first loop depends on the particles being "frozen".
For example, if you calculate the distance of particle 1 in relation to all other particles, then change particle 1 then when you move on to particle 2 then the distance of particle 1 has already changed, so particle 2 will not move in relation to particle 1 as particle 1 moves in relation to particle 2. So you need to do all the calculations in one loop, then change everything in another.
For example, if you calculate the distance of particle 1 in relation to all other particles, then change particle 1 then when you move on to particle 2 then the distance of particle 1 has already changed, so particle 2 will not move in relation to particle 1 as particle 1 moves in relation to particle 2. So you need to do all the calculations in one loop, then change everything in another.
16
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by DSMan195276 on May 12, 2013, 07:18:39 AM »Clippy:
Memory leaks are fixable, it would require decided what to do in that case though, and either option isn't amazingly appealing. Or you could just use _LOADIMAGE and never worry about that specific issue.
I realize you can convert images into icons, it seems slightly pointless to require that though. Regular files can be attached to the EXE just as well as icon files, so there just really isn't much need because I'm under the impression that QB64 doesn't need a 'ico' file anyway. As for what resources would be allowed, no reason to let Windows limit us. As long as you embed the file into the program in some what that's readable then it'll work as expected, and piping over that file to one of QB64's subsystems to handle it shouldn't be that complex of a thing to do.
Galleon:
Ignoring me and Clippy talking about other ideas, all of this looks like nice additions to me. You may want to note that I don't believe it's possible to set a 'Window icon' for Linux. You can set an icon for the task bar but virtually all of the Window manager's I've seen never display an icon in the window decoration. There is one Window Manager that displays an icon for me, but it's always the same as the one in the taskbar (I presume there is no way to set it different). I'm just noting because I don't really know how hard it would be to track this info down, and it's not worth running around in circles
Matt
Memory leaks are fixable, it would require decided what to do in that case though, and either option isn't amazingly appealing. Or you could just use _LOADIMAGE and never worry about that specific issue.
I realize you can convert images into icons, it seems slightly pointless to require that though. Regular files can be attached to the EXE just as well as icon files, so there just really isn't much need because I'm under the impression that QB64 doesn't need a 'ico' file anyway. As for what resources would be allowed, no reason to let Windows limit us. As long as you embed the file into the program in some what that's readable then it'll work as expected, and piping over that file to one of QB64's subsystems to handle it shouldn't be that complex of a thing to do.
Galleon:
Ignoring me and Clippy talking about other ideas, all of this looks like nice additions to me. You may want to note that I don't believe it's possible to set a 'Window icon' for Linux. You can set an icon for the task bar but virtually all of the Window manager's I've seen never display an icon in the window decoration. There is one Window Manager that displays an icon for me, but it's always the same as the one in the taskbar (I presume there is no way to set it different). I'm just noting because I don't really know how hard it would be to track this info down, and it's not worth running around in circles
Matt
17
QB64 Discussion / Re: Help with Physics Simulator
« Last post by SkyCharger001 on May 12, 2013, 06:30:14 AM »A quick glance at the code shows what I know as single-buffer-corruption.
If you use only a single buffer, your calculations will corrupt themselves. (they need the data from the previous iteration, but it's already been replaced with the data from the current one)
It's why double-buffering is a must with simulation.
If you use only a single buffer, your calculations will corrupt themselves. (they need the data from the previous iteration, but it's already been replaced with the data from the current one)
It's why double-buffering is a must with simulation.
18
QB64 GL / Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Last post by Clippy on May 12, 2013, 06:16:46 AM »1) Forget the memory leaks! We cannot fix them? Then why harp on them? Your memory work is leaking all over this place! 
Whatever Windows allows as resources can be used. I have seen bitmaps as resources, but otherwise to embed them properly, they will have to be converted to a proper format. I'm not aware of GIF's as resources, but who knows? The key thing is that it should be located where Windows can find it and other programs can extract it properly.
Galleon, do you mean that all of an icon's images would be loaded if they are in a specified icon file? I'm not sure how Windows decides which image to use. Supposedly it picks the best one for the current settings. The OS version decides what to use in some cases. That's where the IDE could come in handy to make a selection. Just tossing up some ideas.
Icons often have different images to fit different resolutions from 16 X 16 to 64 X 64. I've already figured out the file sizes for bit depths too. The AND map determines the clear parts. I have successfully added AND maps to add transparency too. ANY background color could be made clear if a user wants to do that or a black AND map would have no transparency. All AND maps are padded to 32 bit width multiples so 16 X 16 and 48 X 48 have additional padding of 16 bits.
PS: Imagine custom cursors too! A CUR file is identical to an ICO file except for 2 values for the cursor hot spot. In icons those values are zero.
Quote
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).I have converted images to icons to use them as resources. Just _LOADIMAGE any image and scan it as you would a bitmap. Add the icon header and the AND map for transparency.
Whatever Windows allows as resources can be used. I have seen bitmaps as resources, but otherwise to embed them properly, they will have to be converted to a proper format. I'm not aware of GIF's as resources, but who knows? The key thing is that it should be located where Windows can find it and other programs can extract it properly.
Galleon, do you mean that all of an icon's images would be loaded if they are in a specified icon file? I'm not sure how Windows decides which image to use. Supposedly it picks the best one for the current settings. The OS version decides what to use in some cases. That's where the IDE could come in handy to make a selection. Just tossing up some ideas.
Icons often have different images to fit different resolutions from 16 X 16 to 64 X 64. I've already figured out the file sizes for bit depths too. The AND map determines the clear parts. I have successfully added AND maps to add transparency too. ANY background color could be made clear if a user wants to do that or a black AND map would have no transparency. All AND maps are padded to 32 bit width multiples so 16 X 16 and 48 X 48 have additional padding of 16 bits.
PS: Imagine custom cursors too! A CUR file is identical to an ICO file except for 2 values for the cursor hot spot. In icons those values are zero.
19
QB64 Discussion / Re: Internal's c/c++ compiler
« Last post by mcalkins on May 12, 2013, 06:03:56 AM »both delme.c and delme.cpp:
It seems that g++ compiles as C++ regardless of extension. It seems that gcc relies on source file name extension.
Regards,
Michael
Code: [Select]
#include <stdio.h>
int main() {
if (1 == (sizeof 'a')) {
printf("This program was compiled as C++.\n");
} else {
printf("This program was compiled as C.\n");
}
return 0;
}Code: [Select]
C:\tools\New Folder\bin>g++ -Wall -o delme.exe delme.cpp
C:\tools\New Folder\bin>delme
This program was compiled as C++.
C:\tools\New Folder\bin>g++ -Wall -o delme.exe delme.c
C:\tools\New Folder\bin>delme
This program was compiled as C++.
C:\tools\New Folder\bin>gcc -Wall -o delme.exe delme.cpp
C:\tools\New Folder\bin>delme
This program was compiled as C++.
C:\tools\New Folder\bin>gcc -Wall -o delme.exe delme.c
C:\tools\New Folder\bin>delme
This program was compiled as C.
C:\tools\New Folder\bin>g++ --version
g++ (GCC) 4.8.1 20130328 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.It seems that g++ compiles as C++ regardless of extension. It seems that gcc relies on source file name extension.
Regards,
Michael
20
QB64 Discussion / Re: Full-Motion-Video for QB64 (player and recorder libraries now released)
« Last post by Jobert14 on May 12, 2013, 05:47:07 AM »Actually, loading all frames into memory and displaying each frame one by one is faster than reading from disk and decompressing the frame data. However, its obviously stupid to use that method. I mean, who makes a video player that consumes 80% of your system's memory?
The only problem this MVF video format suffers from is 'sound gapping' because it needs to read a lot of frame data from the disk due to its poor frame compression ratio compared to other video formats such as DivX, H.263, and MPEG. The gapping happens when the program that plays the video can't read data from the disk fast enough to achieve a nearly perfect 30FPS frame rate. The problem could be due to the OS or the disk cache.
The only problem this MVF video format suffers from is 'sound gapping' because it needs to read a lot of frame data from the disk due to its poor frame compression ratio compared to other video formats such as DivX, H.263, and MPEG. The gapping happens when the program that plays the video can't read data from the disk fast enough to achieve a nearly perfect 30FPS frame rate. The problem could be due to the OS or the disk cache.