Help needed translating a C program

[fuzzy70]

If anyone could help translating this small program to GLB I would be very grateful. All it does is read a dat file & saves it as a bitmap, I am not worried about it saving the bitmap as such as what I was trying to do was read it into an array & then MEM2SPRITE the array.

However my C coding is about on par as elephant running the Grand National & got nowhere fast. I even installed code::blocks & built SDL (not one of my most fun experiences I have to admit) & just got build errors trying to compile the included code.

So any help would be great 

Lee

Code (glbasic) Select Expand


// gcc -Wall -g dat2bmp.c -o dat2bmp `sdl-config --cflags --libs`

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
#include <errno.h>
#include <string.h>

#include <SDL.h>

#define ERROR_PRINTF(...) { fprintf(stderr, "%s:%s:%u Error: ", __FILE__, __PRETTY_FUNCTION__, __LINE__); fprintf(stderr,__VA_ARGS__); fflush(stderr); }

int main(int argc, char** argv)
{
FILE* f = NULL;
uint32_t *tmp = NULL;
const char *bmp = NULL;
const char *dat = NULL;
SDL_Surface * g = NULL;

if (argc < 3)
{
fprintf(stderr, "Usage: %s file.dat file.bmp\n", argv[0]);
return -1;
}

dat = argv[1];
bmp = argv[2];

f = fopen(dat, "rb");
if (!f)
{
ERROR_PRINTF("Unable to open file %s: %s", dat, strerror(errno));
return -1;
}

short w,h;
fread(&w, sizeof(w), 1, f);
fread(&h, sizeof(h), 1, f);

if (w>1500 || h>1500)
{
ERROR_PRINTF("Invalid file %s", dat);
return -1;
}

tmp = (uint32_t *)calloc((int) w * h, sizeof(uint32_t));

uint32_t c = 0;
uint32_t cnt = 0;
int p = 0;
for (p = 0; p < (int) w * h; p++)
{
if (cnt)
cnt -= 0x1;
else
{
fread(&c, sizeof(c), 1, f);
cnt = c >> 24;
if (cnt==255)
fread(&cnt, sizeof(cnt), 1, f);
}
tmp[p] = c | 0xff000000;
}

g = SDL_CreateRGBSurfaceFrom(tmp, w, h, 32, w*4,
0xff0000,
0xff00,
0xff,
0xff000000 );

if (SDL_SaveBMP(g, bmp) == -1)
{
ERROR_PRINTF("Unable to write BMP file %s: %s", bmp, strerror(errno));
return -1;
}

fclose(f);
free(tmp);
return 0;
}



[TI-994A]

I even installed code::blocks & built SDL (not one of my most fun experiences I have to admit) & just got build errors trying to compile the included code.

I feel for you man! 

Just spitballing, but since the original routine is in C, wouldn't it be possible to INLINE the code and get the results returned to a GLBasic array, as done by Gernot here:

return a C/C++ array to GLBasic (INLINE)

[fuzzy70]

It would be a possibility if I understood how arrays etc (as well as the fread statement, sizeof ) work in C lol.

I have made slight progress with getting code::blocks & sdl in that I'm getting fewer errors at build time.

Basically I want to use it to convert the dat files that came with a game to view the graphics tileset. The game came with the source code & the tileset would be very useful to me for planning & creating my own set for what I'm working on.

For those that are interested it they are in isometric hex form & seeing how the author made their set will help me generate my own.
I have wrote a simple isometric hex tile plotter, which was not immediately obvious to create being so used to standard square types

Lee

Sent from my HTC Wildfire using Tapatalk 2

[bigsofty]

It looks quite simple to convert, can you post a couple of small .DAT files to me for testing?

[fuzzy70]

Hi Bigsofty, I have attached all the dat files zipped that come with the game. There are 8 in total & I presume the "tiles.dat" is the one I require (assuming the originator named his files logically  ).

I managed to work out from the source code I posted earlier that the 1st short is the width & the 2nd is the height of the final bitmap, but working out how the pixels are stored after that is what is causing me problems. I also tried taking a screenshot from the game but due to they way they are laid out plus a water effect it was impossible to get a clean rip of a tile.

Obviously I can get the top of the tile from a grab no problem but it is the base & how the tile is laid out as a whole that I'm after.

If you can help that would be great, it's not a urgent matter as I am still working on my tile plotter. Hex tiles by themselves are not a problem as you can draw them pretty much like any normal grid, however throw isometric into the mix along with a base & it's a different story as draw order makes or breaks it .



Lee

[hardyx]

I compiled the C program for you, this is the executable for Windows. I hope this helps you.

[bigsofty]

So... to translate or not to translate, that is the question? 

[fuzzy70]

I compiled the C program for you, this is the executable for Windows. I hope this helps you.

Thank you for doing that Hardyx, I can now look at the tileset & use it as a template for my own project as well as test my tile engine is drawing correctly 

So... to translate or not to translate, that is the question? 

Thanks for the offer of translating it Bigsofty  . The author also supplied a bmp2dat source which might be of use to anyone that wants to code their graphics in a non standard way then convert them into sprites at startup.

The tiles.dat file is 116k whereas the resulting tiles.bmp is 841k so not sure how the have been encoded.

Lee

[bigsofty]

NP. It looks like a simple RLE file compression, hence the smaller file size.

[fuzzy70]

I think I might have to set a little bit of time aside to learn some C/C++, nothing huge just basic things like arrays & operators.

The code I posted is short & while I understand FOR loops & IF structures (along with the need for braces {} & ; etc) most of the rest means nothing, like the * & ** >> etc hence my failure to being able to convert it myself. That & not being able to compile what is in essence a simple program warrants a bit more investigation on my part I think   

Lee

[TI-994A]

I compiled the C program for you, this is the executable for Windows.

Hello hardyx. Just out of curiosity, would the routine work if it was INLINE'd within a GLBasic project?

[hardyx]

Hello hardyx. Just out of curiosity, would the routine work if it was INLINE'd within a GLBasic project?

The C code is a command line program, could work with INLINE, but with some modifications. Maybe converting the program to a function and calling it from GLBasic.

[hardyx]

The code I posted is short & while I understand FOR loops & IF structures (along with the need for braces {} & ; etc) most of the rest means nothing, like the * & ** >> etc hence my failure to being able to convert it myself. That & not being able to compile what is in essence a simple program warrants a bit more investigation on my part I think   

Analizing the code I see that the input .dat files are compressed using a simple method. The file has a little header with the width and height of the original image. Next there are the image data in groups of 4 bytes with CRGB, being C the times to repeat the pixel colour RGB, from 1 to 254. If a pixel must to repeat more than 254 times, then CC=255 and the count is in the next 4 bytes (integer), like: xxRGB NNNN. Its a RLE compression like bitsofty said.

[fuzzy70]

Thanks Hardyx for the explanation 

What you describe I could easily write in Basic (plus Pascal if needed), but even that small part of C threw me so I think I will learn a bit about C style operators & arrays as may come in handy for future. Might help me understand so more INLINE posts I seen on this forum & such.

Lee

[MrTAToad]

The main problem (if you went with INLINE) would be to replace the fsteam (fopen/fclose etc) functions with open (as GLBasic doesn't use the former) - and as read/write are somewhat different to fread/fwrite it will be... fun...

Thus it's a matter of converting to GLBasic.  But then there is the SDL access, which would require INLINE functions, function declarations and after all that you may or may not have access to the functions anyway...

And I don't want to mention the structures, just in case it puts you off the conversion...