How does one read or write files (png, txt, jpg...) in OpenGL ES? Target is Android through Visual Studio.
Unfortunately it's not as simple as placing the assets in the same directory as the main program and then referencing them using fstream.h or stdio.h like with the Opengl equivalent. I've tried creating folders like res/raw and using android/asset_manager.h and similar libraries. Is it even possible through this IDE? I'll be done in Unity by the time this gets resolved...
You don't. OpenGL is an API concerned with transforming vertices, and drawing pixels on a screen. File formats are outside the definition of OpenGL. In other words, if you want to use a *.png as an input/output format, you'll need to find a 3rd party library that supports that file format (e.g. libPNG), and use that to transfer the pixel data to OpenGL.
The raw file stream classes (e.g. ifstream) have zero concept of a file format. Again, another reason why you use a 3rd party library.
Unity is a full fledged game engine, and as such has spent time building support for various file formats (e.g. PNG, obj, etc). OpenGL is far lower level that that. A good place to start for image data, is a lib such as DevIL (which itself includes other 3rd party libraries such as libPNG, libJPEG, etc).
Related
As i catch it structure D3DX11_IMAGE_LOAD_INFO is deprecated in DX 11 for Windows 8.1 and up, what kind of structure can i use for replacement for this structure.
D3DX11_IMAGE_LOAD_INFO is part of the D3DX11 utility library from the DirectX SDK.
D3DX9, D3DX10, and D3DX11 are all deprecated along with the legacy DirectX SDK. See MSDN for the full details here.
Depending on what exactly you were wanting to do with D3DX11 here, there are a number of different options (all of which are open source under the MIT license).
The DirectXTex library provides the functionality in D3DX for loading bitmaps, resizing and converting them, generating mipmaps, compressing, and then writing them out as .DDS files. This is usually overkill for most applications to do at run-time, and not a particularly good use of end-user's time anyhow, but it's great for writing custom content tool pipelines for texture processing. The DirectXTex package includes a 'sample' which is the venerable texconv command-line tool written to use DirectXTex instead of D3DX.
The DDSTextureLoader module is intended to handle efficient loading of .DDS files and creating Direct3D 11 resources from them. It does not perform any runtime conversions, so some legacy files with pixel formats that do not directly map to a DXGI format will fail to load and in some cases the DXGI format of the file is not supported by the device and will also fail to load. For these cases, you will want to use DirectXTex to convert them offline to something that you can rely on being able to load on your target machine. This code supports the full range of Direct3D 11 resources including 1D, 2D, 3D, cubemaps, and texture arrays with mipmaps. The DDSTextureLoader module is included in both the DirectXTK library and in the DirectXTex package.
For very simple cases, there is also a WICTextureLoader module which can load standard bitmap files, does some runtime conversions and resizing, and then creates a Direct3D 11 texture 2D from it. It can optionally enable the 'auto-gen mipmaps' feature of Direct3D 11 to provide some basic mipmap support as well (standard bitmap files can't store mipmaps with the base image the way a .DDS file can). This makes use of the Windows Imaging Component (WIC), but is much more 'heavyweight' than DDSTextureLoader. This gives you less control over the quality of the filtering (particularly mipmaps), and does not support complex textures like volume maps, cubemaps, or texture arrays. The WICTextureLoader module is also included in both the DirectXTK library and in the DirectXTex package.
The ScreenGrab module is intended as a light-weight texture saver for creating 'screen shot' bitmap files from render target textures. The ScreenGrab module is included in the DirectXTK library and DirectXTex package.
-- excerpt from this post
For a complete catalog of replacements for legacy D3DX, see this post. There are similar posts for samples, tools, and the DirectX components.
Since you've marked this question with the VS 2013 tag, I'm assuming you are using Visual Studio 2013. You should read about the Windows 8.1 SDK that comes with it. There's a NuGet package for DirectX Tool Kit that works with VS 2013 Update 5, as well as a "Direct3D Game" template package for VS 2013 that you might want to check out.
I've read this DirectX 11 tutorial on VS2015 (http://www.rastertek.com/dx11s2tut04.html), and found out that the author compiles the vertex and pixel shader separately, using the .vs file and .ps file respectively.
And I also found out that in the book "3D Game Programming with DirectX 11" the author use .fx file to organize the shaders throughout the book.
Which method should I use to develop my direct3D program with the latest version of Windows SDK, I wonder? Since I've heard that the Effects11 framework might be deprecated in the future.
You should avoid using fx targets for new projects, and opt for per-stage compilation instead. Note that this is independent of whether you actually put your shader code in separate files, though having one .vs or .ps per shader is a common convention. Full D3D11 support for effects profiles (i.e. fx_5_0) is already deprecated in the latest (Windows 10) compiler, and there is no fx_5_1 at all (some directx-12 features require shader model 5.1).
I am in Mac OSX, Cocoa .
I want to read and write multi layered .psd images.
With Cocoa native api's i can read or write the images as flat images.(i.e., single layered)
So is there any 3rd party library available to perform the operations?
This is my earlier query.
psd Image creation with layer properties using CGImageRef
Thanks,
Dhana
PSD is a lousy format for anything but use in PhotoShop, and most third party libraries will miss some of the finer points of layer composition, in part because Adobe keeps extending the format, and in part because it isn't extremely well documented.
If you need to keep altered images in PSD, then presumably you have PhotoShop in-house. Your best bet is to use Photoshop Batch Processing which can be as easy as keyboard macros or as complex as you want to script.
I have tried everything from SDL to DevIL, and they have all failed for various reasons.
SDL segfaults for various reasons, and DevIL is having some weird problem where even after i include IL/ilut.h and linking everything, and including the other headers, it is not defining the functions i need to load images into opengl textures (something about USE_OPEN_GL not being defined). I am asking for any other lib out there for loading bitmaps or png's into a format i can easily convert to opengl, or a solution to the devil problem.
thanks
Both libpng and libjpeg can be rather daunting to build & use -- no wonder there are all sorts of wrapper libraries for both.
A very simple and minimal no-nonsense loader for jpg/png (and some other stuff aswell) without dependencies in a single C file is Sean Barrett's stb_image.c, if you just want to load some image files it adds absolutely minimal overhead to your program and is straightforward to use:
http://nothings.org/stb_image.c
As Adam suggests, I would also recommend to use libpng and libjpeg. You are not specifying if you write in C or C++, but if in C++, then I'd suggest to take a look at two handy thin wrappers on the both libraries: pngxx and jpegxx
LodePNG is a highly compact PNG Loader with no dependencies.
Comment on your experience with DevIL - it works flawlessly for me and many others. Why not try again to resolve your build problems? - shouldn't be too hard)
You can also try FreeImage library. It supports loading different image types and is functionally similar to DevIL, may work out of the box for you.
And about your problem with DevIL, you do not have to build ilu or ilut libraries to make DevIL functional. I would recommend you manage the OpenGL texture objects yourself, including uploading image data to OpenGL side.
SOIL is a decent lightweight one I've used before. It's actually specialized for loading OpenGL textures too.
http://lonesock.net/soil.html
you dont need ILUT to do what you want. you can simply use ilGetData() and glTexImage2d()
Loading bitmaps (.bmp) and netpbm images (.pbm, pgm, .pnm) is fairly trivial, since they store images uncompressed. For loading PNGs, use libpng. For loading JPEGs, use libjpeg. For other image types, use an appropriate library. There's a good change that slapping on 'lib' to the beginning of the image name will give you such a library, e.g. libtiff, libtga, etc.
Once you've loaded and uncompressed the raw image data, loading it into an OpenGL texture is just a matter of calling glTexImage2D() with the right parameters, and a couple of other GL state changes (e.g. how to do mipmapping).
Image Magick with either the C or C++ bindings?
http://www.imagemagick.org/script/index.php
Young but yet great enough SFML could be the one you're searching for. I've used it for numerous projects and all of 'em worked well on all my platforms (Win7 and Ubuntu).
I would like to create a file format for my app like Quake, OO, and MS Office 07 have.
Basically a uncompressed zip folder, or tar file.
I need this to be cross platform (mac and windows).
Can I do something via command prompt and bash?
If you want a single file that is portable to all platforms and which contain structured data, consider using sqlite. You'll get a full featured ACID compliant database that exists on disk as a single file.
There are libraries you can link against to directly access the file, and there is a command line tool you can use as well. No matter what language you are using, most likely there is support for it.
http://www.sqlite.org
Have a look at the open source 7Zip compression format. For your specific needs, you can use it in an "Archive" mode, zero compression but very fast.
It provides a powerful SDK, LZMA, from the site:
"LZMA is the default and general compression method of 7z format in the 7-Zip program. LZMA provides a high compression ratio and very fast decompression, so it is very suitable for embedded applications. For example, it can be used for ROM (firmware) compressing.
The LZMA SDK provides the documentation, samples, header files, libraries, and tools you need to develop applications that use LZMA compression."
Zip is supported everywhere. If a container is all you need, than those are surely good options.
SQLite is great.
A single file, crossplatform, a tiny library, SQL access to data, transactions, the whole enchilada.
you can use transactions to guarantee consistent return points in case of crashing. check uses for sqlite, they specifically advocate using it as a data model layer for desktop applications.
also, there's a command-line tool to manually access the data.
First thing you should ask yourself is, "Do I really need to make my own?"
Depending on what you want to use it for, you are probably better off using a common format and some pre-made libraries which already handle one of those formats very well.
Good places to start:
http://www.destructor.de/libtar/index.htm (tar -- a the 'container' format)
http://www.zlib.net/ (zlib -- a method of compressing data before or after you put it in the container)
If you still really think you need to make your own, I would suggest studying something very simple first, like tar's format:
http://en.wikipedia.org/wiki/Tar_(file_format)
or
http://schmidt.devlib.org/file-formats/tar-archive-file-format.html
Instead of making a format, I'd just decide on a convention. One or more named files within the container have the metadata you need to access the rest of the files, and know what to do with them. The container itself, though, should just be some ubiquitous format, such as zip. No need to reinvent the wheel, here.