Hi,
Currently SaveScreenshot only saves BMP and PCX. Right? It would be possible to also save JPG files?
I ask this, because I'm bulding a record module, that would allow you to record to iamges what it is happening on screen. This is nice, since then you can use virtual dub to create a video from the images. The problme is that BMP or PCX do take lots of disk space, maybe has JPG it would take less space.
Can this new feature be implemented?
There are easier ways to do this... programs exist that let you record whatever is going on in your screen, and that is better encoding than a series of JPEGs.
Besides, JPEG is a lossy format.
What about PNG, it's lossless compression and it does make it a lot smaller than BMP?
Well, I think one reason was the JPEG compression scheme was a bit complicated compared to the retard (not actually, depends on how the image's like) RLE scheme used by PCX (BMP files are uncompressed), so you may need a fast enough (depends) computer to save a compressed shot during gameplay (especially when you need to do it continuously).
Furthermore, JPEG uses lossy compression so the saved images will degrade in quality (it may not be that important in some instances and for some of the people however) and you can use some other programme to batch convert the images to smaller format anyway.
On the other hand I do see how this may be useful, if you save shots continuously in formats like BMP or PCX you may need HUGE working HDD space, and in some case it may be possible that writting huge amount of data to disk would slow stuff anyway, sometimes for fast system the compression time is even faster than writting data, so in taht case saving as JPEG might be useful.
However, I think writting large number of frames continuously using AGS itself might not be that preferable, as there're programmes out there that can do stuff more efficient by recording the output of a window (like an AGS game say for example) directly.
Someone posted faster than me, but anyway, the same goes for PNGs, it's probably even more CPU power hungry to save consequtive frames in PNGs than in JPEG anyway.
PNG support for in-game import/export would be nice. The compression is good, and it's already support in the editor. In this case it would probably be too much for the CPU, but for regular screenshots it shouldn't be a problem (especially since you usually end up using wait(1) anyway to hide GUIs etc.)
Edit: It would also be nice, if you could save/import images with a different file extension than the actual format. If you use external files to store large DynamicSprites (e.g. altered backgrounds) to save memory, it would at least add some degree of security if the user wasn't aware of the file format. This could be done with an optional parameter like sprite.SaveToFile("RotatedAvatar.dat", eBmp) or SaveScreenShot("101.tmp", ePcx)
/me seconds GG
Well,
Thanks for the fast awnsers.
I've already tried those so called programs, but they work very bad. They recomend 5 frames per second, which is a low value. I'm trying to capture 800x600 images, and it should be fast enought o allow at least 20 frames per second. Using AGS, the game becames slower, but I get almost all the frames, which is good, beucae they i can use VirtualDub to create a video.
But my module, works fine, but less then 10 seocnds take 500Mb in BMP format. I think the JPG format would be nice, since is fast encoding. PNG is better but would take more time to enconded, making the game slower.
If any fo how have a way to capture DirextX 2D surfaces from a game taht woul be nice. There is program for 3D games, which is Fraps, but it doesn't work on 2D.
Actually it doesn't matter if the game runs slower while recording, as long as you take a shot every X game cycles rather than every X seconds. If normally the game runs at 40 fps and you take a shot every 4 frames, then it doesn't matter if the game runs twice as slow while recording, as long as you can play it back at 10 frames per second.
You can significantly reduce size here by using a lesser color depth or a lesser resolution. AGS isn't particularly fast in 800x600x16bit to begin with.
The game I've is 800x600 32bits, so it is not really an option to reduce the screen resolution.
The only problem with the slow down is with sound, since the sound doesn't slow down.
The solution might be to disable speech voice, which then might enable to have the text on screen enough time.
Currently, I'm getting every frame. which is good enough, but maybe I could cahnge that to half of the speed or quarter of the speed.
I've to take a look and test, but saving it has JPG would be nicer and HDD saver.
I don't want to add JPG or PNG support to the game engine because the encoders/decoders are quite large, and they would bloat the size of the ACWIN.EXE significantly -- I don't want the engine ending up as big as the editor EXE is!!
To get this functionality, you'll have to write a plugin.
Just to state the obvious, in scripting - repeatedly_execute_always:
DynamicSprite *s = DynamicSprite.CreateFromScreenShot();
JPGWriterPlugin.Write(jpgName, s.Graphic);
s.Delete();
If you need some help with the plugin, let me know. I've got some code at home I can look over.
Curentrly the problem with plugin, is that they only work in Windows, and I thinking in the future to make the games available to MAc, but for this purpose, I guess the plugin should be ok.
Thanks for the help.
Plugins work with the mac engine too.
You need to compile the plugin on a mac.
Ok, thanks.
Any chance of getting the some help on this? I've downlaod the template in Delphi, but I was not able to take much time to undersatnd it. I guess I must wait until I finish this game.
I'm not sure it will be possible to get away from quite big file sizes for frame sequences. I'm certainly no expert in compression but If I understand correctly, video compressors use key frames, which are big, and in-between frames, which are smaller. If you're recording a frame sequence the size must always be higher.
On the other hand, PNG screenshots would be considerably smaller than BMPs, so I'd endorse that feature.