3.2.0-5 note

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

Post Reply
User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

3.2.0-5 note

Post by Holger » Wed Dec 28, 2005 3:16 pm

A little note for HerzAusGold:

The current pre-release package also contains the Perl script which generates the C files "src/conf_*.c" from other source files which are then included.

The conf files are automatically re-created when the depending C source files have changed, or explicitly by "make auto-conf".

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

VC support is ready soon

Post by HerzAusGold » Thu Dec 29, 2005 8:48 am

Thanks. Great. You are in time ;)
The VC Workspace is ready, I only have to tidy up my changes.

preparation:
Using "SHGetFolderPath" needs SDK2003 to installed (200MB-1000MB). Arrgh - It's a Online-Installation.
It seems this is the only WINDOWS-Call - May be an environment like RND_HOME would like
better here. (and the DOS version may be alive)

main changes:
- rename CONF_xxx.c to CONF_xxx_c.h (if necessary)
- make a scanFileDir interface to get all files (DIR,readdir is not available)
- char buffer[maxlen] seems not allowed - do an alloc
- inline is a c++ feature - define away
- var declaration in code is a c++ feature - change
- some other changes

may be todo:
you use different types as the SDL do, may be this cause a problem
(first i want test this - then release the source - and then changing)

return SDL_MapRGB(bitmap->surface->format, color_r, color_g, color_b);
warning C4761: integral size mismatch in argument; conversion supplied

btw: As little sideeffect now all DIR-access are prepared to use it in a transparent way. HeHe!

Is there any change to merge the changes with your code? I don't want to do for each release. (...But I do it....)
And the answer is ... 42 !

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Thu Dec 29, 2005 10:12 am

> Using "SHGetFolderPath" needs SDK2003 to installed (200MB-1000MB).
> It seems this is the only WINDOWS-Call - May be an environment like
> RND_HOME would like better here.

Hm. But how would it be set then?

I use the "SHGetFolderPath" stuff for getting the Windows specific paths, like "My Documents", which differs from Win95/98 to Win2k/XP, for example.

> (and the DOS version may be alive)

This stuff is independent from the DOS version, which uses a fixed path.

> main changes:
> - rename CONF_xxx.c to CONF_xxx_c.h (if necessary)
> - make a scanFileDir interface to get all files (DIR,readdir is not available)

Really? So this is Unix/Cygwin specific...

BTW: Any reason why not using Cygwin/C for compiling? Should make these things a lot easier. Maybe it's possible to use an IDE with Cygwin/gcc? (But I have really no experience here...)

> - char buffer[maxlen] seems not allowed - do an alloc

Hmm, is this C99?

> - inline is a c++ feature - define away

Yes, "inline" is not C89/C99, but a GNU/gcc extension, if I remember correctly...

> - var declaration in code is a c++ feature - change

Where have you found this? I thought my code is (more or less) C89?
But variable declarations in code are allowed since C99, or am I wrong?

> you use different types as the SDL do, may be this cause a problem

Any examples? Not really sure if I know what you mean here...

> btw: As little sideeffect now all DIR-access are prepared to use it in a
> transparent way. HeHe!

Yes, wrapping things away help to be platform independent. We could do this with the DIR/readdir stuff, of course. No idea how VisualC does this, but if you tell me, I'll check this.

> Is there any change to merge the changes with your code? I don't want to
> do for each release. (...But I do it....)

If the changes can be wrapped away in a decent way, I see no big problems here. If VisualC does not force too many unneeded language restrictions that require really dirty changes, it should be possible to merge in your changes. (But I'm really not totally sure which language features are C89, C99 or GNU/gcc extensions, so I would have to check this for myself, too. If we use a decent subset like C99, we could get away with it... :-) )

Guest

Post by Guest » Thu Dec 29, 2005 11:40 pm

Upload source rndTest-0-3src.zip
http://www.zomis.net/rnd/download.php?id=393

Test this with Eclipse (Cygwin), MinGw and VisualC.
(for Eclipse you should have 1GB Ram and a 3GHz CPU - better two)

In Cygwin you have to define CYGWIN

Hm. It seems in MinGw its necessary to define VISUAL_MINGW_CPP.
(otherwise Dir-Access fail). Don't know really why.

In VisualC you have to define TRAGET_SDL, VISUAL_CPP and VISUAL_MINGW_CPP.

Its now ANSI-C ! VisualC is a hard tester in this case. Believe this.
I dont know something about C89/C99.

Now the changeLog: (search for #HAG#VC)
--------------------------------------------------------
VC6 - Workspace - change log - by HerzAusGold
-------------------------------------------------------------------------
hash.h - define away 'inline' (its an c++ feature)
- comment body of iterator functions (its twice, c++)
-------------------------------------------------------------------------
list.c - include 'rndapi.h'
- fileScanDir, fileScanDirFree
-------------------------------------------------------------------------
list.h - fileScanDir, fileScanDirFree
(using a pointer to an array of pointers to dirent)
-------------------------------------------------------------------------
sdl.h - define away 'inline'
-------------------------------------------------------------------------
setup.c + LoadLevelInfoFromLevelDir
+ LoadArtworkInfoFromArtworkConf
+ LoadArtworkInfoFromArtworkDir
+ checkSeriesInfo
- DIR access with fileScanDir, fileScanDirFree
- using macro S_ISDIR
-------------------------------------------------------------------------
sound.c + LoadCustomMusic_NoConf
- DIR access with fileScanDir, fileScanDirFree
- (macro not needed)
-------------------------------------------------------------------------
text.c - 'buffer' alloc/free at runtime
-------------------------------------------------------------------------
zfile.c - DIR access with fileScanDir, fileScanDirFree
- using macro S_ISDIR
-------------------------------------------------------------------------
cartoons.c - 'void' missed
-------------------------------------------------------------------------
conf_chr.c -> conf_chr_c.h
conf_cus.c -> conf_cus_c.h
conf_e2g.c -> conf_e2g_c.h
conf_esg.c -> conf_esg_c.h
conf_fnt.c -> conf_fnt_c.h
conf_g2m.c -> conf_g2m_c.h
conf_g2s.c -> conf_g2s_c.h
conf_grp.c -> conf_grp_c.h
-------------------------------------------------------------------------
conf_gfx.c - rename includes conf_xxx_c.h
-------------------------------------------------------------------------
editor.c + editor_hl_custom_more
+ editor_hl_custom_special
+ editor_hl_group_more
+ editor_hl_empty (hope this is ok)
- empty arrays are not allowed (c++)
- 'infotext' alloc/free at runtime
- 'buffer' alloc/free at runtime
-------------------------------------------------------------------------
events.c - add comment to 'soko step' (for later use)
- define 'keyend' at the top (c++)
- setting variable 'keyend' (recommended)
-------------------------------------------------------------------------
files.c + getPackedLevelBasename
+ LoadMusicInfo
- DIR access with fileScanDir, fileScanDirFree
- (macro not needed)
-------------------------------------------------------------------------
game.c - define 'nextseries' and 'i' at the top (c++)
- define a block for my sokoban stuff
- return void (CheckGravityMovement) is not allowed (c++)
-------------------------------------------------------------------------
init.c - rename includes conf_xxx_c.h
-------------------------------------------------------------------------
main.c - 'void' missed
-------------------------------------------------------------------------
soko.h - named struct 'step_t' (recommended)
-------------------------------------------------------------------------
tools.c - 'void' missed
- 'text_line' alloc/free at runtime
-------------------------------------------------------------------------
tools.h - 'void' missed
-------------------------------------------------------------------------
windows_icon.ico .bmp is missed! BMP2ICO.EXE is missed too!
-------------------------------------------------------------------------
include - change some includes <unistd.h>, <dirent.h>,
<sys/time.h> not defined in WIN32
- inherit rndapi.h
-------------------------------------------------------------------------

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

VisualC

Post by HerzAusGold » Fri Dec 30, 2005 9:01 am

Sorry for reply under guest, but it was late yesterday...

>> Using "SHGetFolderPath" needs SDK2003 to installed (200MB-1000MB).
>> It seems this is the only WINDOWS-Call - May be an environment like
>> RND_HOME would like better here.
>
>Hm. But how would it be set then?

In an .bat file or a script file.

>
>I use the "SHGetFolderPath" stuff for getting the Windows specific paths, like "My Documents", which differs from Win95/98 to Win2k/XP, for example.
>
>> (and the DOS version may be alive)
>
>This stuff is independent from the DOS version, which uses a fixed path.
>

So, what else causes to be NO DOS version?

>> main changes:
>> - rename CONF_xxx.c to CONF_xxx_c.h (if necessary)
>> - make a scanFileDir interface to get all files (DIR,readdir is not available)
>
>Really? So this is Unix/Cygwin specific...

No this is VisualC specific (and some other IDEs like CodeBlocks expect this)

>
>BTW: Any reason why not using Cygwin/C for compiling? Should make these things a lot easier.
>Maybe it's possible to use an IDE with Cygwin/gcc? (But I have really no experience here...)
>

Yeah I use Eclipse (But this need 1 GB of RAM and a 3GHz CPU, better two)
The main reason was: Only full compile is possible here. (sideeffect of CONF_xxx files)

>> - char buffer[maxlen] seems not allowed - do an alloc
>
>Hmm, is this C99?
>

No in ANSI-C you cant define a 'char buffer[maxlen];' with variable length. In CPP you can.


>> - var declaration in code is a c++ feature - change
>
>Where have you found this? I thought my code is (more or less) C89?
>But variable declarations in code are allowed since C99, or am I wrong?
>

May be, but not in ANSI-C.
Upps. Only my own code...

>> you use different types as the SDL do, may be this cause a problem
>
>Any examples? Not really sure if I know what you mean here...
>

>>>return SDL_MapRGB(bitmap->surface->format, color_r, color_g, color_b);
>>>warning C4761: integral size mismatch in argument; conversion supplied

Here the colors are 'unsigned int' and in SDL they are 'uint8'.
But I dont checked what X11 need.

>> btw: As little sideeffect now all DIR-access are prepared to use it in a
>> transparent way. HeHe!
>
>Yes, wrapping things away help to be platform independent. We could do this with the DIR/readdir stuff, of course.
>No idea how VisualC does this, but if you tell me, I'll check this.
>

Look to fileScanDir.
Oh no. Now I step down from the cable i stand on. And a light go on.
I now know the reason why MinGw-Exe find no Dirs. Umpf. The readdir implementation
is not complete. (reclen is filled with 0 always).

>> Is there any change to merge the changes with your code? I don't want to
>> do for each release. (...But I do it....)
>
>If the changes can be wrapped away in a decent way, I see no big problems here. If VisualC does not force
>too many unneeded language restrictions that require really dirty changes,
>it should be possible to merge in your changes. (But I'm really not totally sure which language features
>are C89, C99 or GNU/gcc extensions, so I would have to check this for myself, too.
>If we use a decent subset like C99, we could get away with it... :-) )
>

Using ANSI-C makes it possible that anyone can use his prefered IDE. And RnD becomes compileable on
more systems. (All which SDL is supported).

Now (for rndTest-0-4) I want to use your scripts to generate the CONF-files. Hope this is possible....
And the answer is ... 42 !

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Fri Dec 30, 2005 12:32 pm

> In an .bat file or a script file.

Yes, but how does this script know the right path?

It's better to just use the correct Windows API which is available for all relevant Windows versions.

Starting R'n'D via a .BAT script sucks. ;-)

> So, what else causes to be NO DOS version?

I was too lazy to install a msdos-cross-compiler on my new computer. :-)

And I wanted to see if there is anybody left out there who uses the DOS version (and would ask for a 3.1.1 update then). Nobody does so far, so I'm thinking about letting the DOS version silently die... :-)

>>> - make a scanFileDir interface to get all files (DIR,readdir is not available)
>>>
>>Really? So this is Unix/Cygwin specific...
> No this is VisualC specific (and some other IDEs like CodeBlocks expect
> this)

But this has nothing to do with an IDE, but with the C libraries you use.

In any case, the best way then is to build a wrapper for these functions, so that the main code uses "DIR" and "readdir", which is wrapped away for broken platforms that don't know this.

>>> - char buffer[maxlen] seems not allowed - do an alloc
>>Hmm, is this C99?
>No in ANSI-C you cant define a 'char buffer[maxlen];' with variable length.
> In CPP you can.

Well... R'n'D is written in C, not C++, so lets stay with C.

BTW: The current ISO/ANSI-C *is* C99. I think it should be possible to do "char buffer[var]" in it. (Could somebody verify this?)

>>> - var declaration in code is a c++ feature - change
>>Where have you found this? I thought my code is (more or less) C89?
>>But variable declarations in code are allowed since C99, or am I wrong?
>May be, but not in ANSI-C.
>Upps. Only my own code...

So it was just a bug in your code?

As "ANSI-C" is "C99", you should be able to declare variables in a block after lines of code. But I usually don't do this and stay with C89 here. Should change this, as it's sometimes more readable...

> Using ANSI-C makes it possible that anyone can use his prefered IDE.
> And RnD becomes compileable on
> more systems. (All which SDL is supported).

That's definitely a valid goal.

But as I said, if you have a C compiler that claims to be "ANSI-C", but does not know anything about "C99", it's probably outdated (or broken) and should not be supported using dirty hacks...

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

dirent.h and the dirty hacks

Post by HerzAusGold » Wed Jan 04, 2006 7:51 pm

Hi Holger,
I moved dirent, DIR, readdir and all directory reading stuff to
fileScanDir. Now it's only return a list of dirNames.

cause' of different dirent implementations.
look on the dirent definition:

The dirent structure is defined below.
struct dirent {
long d_ino;
off_t d_off;
unsigned short d_reclen;
char d_name[1];
};

hp-ux says d_reclen is the whole record size include dynamic d_name (and a gap)

sinix,aix,ultrix,sinix and DigitalUnix say (more or less) the same (without gap).

mingw have d_reclen always 0. (look to definition of FILENAME_MAX - funny comment)

cygwin have no d_reclen!

linux (found in LSB2.0) say d_reclen is len of name.
the man pages say the same.

So the only thing is 'd_name' (null terminated) which is really useable.
(the size of d_name differ, though)

As I mentioned I dont develop on linux (calling make and build a new kernel - is not developing for me... :wink: )
But on the other systems above (and more, but the list is to long :roll: )

Btw: I start continue with the transparent zip support.
If I have some questions, i think it's the best to send an email to you.

C99 is supported to 98% by VC7...hey,VisualStudio2005 is free today!
And the answer is ... 42 !

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Sat Jan 07, 2006 1:13 am

> I moved dirent, DIR, readdir and all directory reading stuff to
> fileScanDir. Now it's only return a list of dirNames.
>
> cause' of different dirent implementations.
[...]
> So the only thing is 'd_name' (null terminated) which is really useable.

So it seems indeed reasonable to wrap away those things which are different on different platforms.

BTW: Wouldn't it work to just use d_name? I think the other fields aren't needed for parsing directories anyway? Then there wouldn't be any differences anymore...

> Btw: I start continue with the transparent zip support.

Cool! Do you transparently extract them (and then access the resulting files), or do you directly read the data from the zip archives? I would prefer the latter method, because it's less intrusive (although slower for small archives).

> If I have some questions, i think it's the best to send an email to you.

Just as you like or prefer! If others are also interested in this topic or have ideas or comments, this sub-forum might also a good place.

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Wed Jan 11, 2006 11:59 am

BTW: Wouldn't it work to just use d_name? I think the other fields aren't needed for parsing directories anyway? Then there wouldn't be any differences anymore...
Yes,of course. But first I have a list of dirent, now only char pointers to the name. Because I read the dir in one step - my mistake.
Cool! Do you transparently extract them (and then access the resulting files), or do you directly read the data from the zip archives? I would prefer the latter method, because it's less intrusive (although slower for small archives).
Directly read the data its the prefered method.
...questions...
Transparent zip support is now implemented - so far.
But reading PCX or WAV,MOD file is 'given' to the SDL-routines.
So all levelinfo.conf and other .conf files loaded but
this files itselfs can't be open. Bad because failure in artwork loading causes exit.

Any way to load the data and give a pointer to the SDL-routines.
e.g loadImage.
Can you help here? - I dont want to rewrite the SDL/X11 lib for zip support. :shock:

Should the access thread save (e.g for music ) ?

Write to zip files not supported - Necessary? I think no.

And the main question: What tab indent do you use? :wink:
I prefer "tabs converted to spaces" indent = 2.

If you want I can send you the source (before I do this I have to tidy up my changes).
And the answer is ... 42 !

User avatar
Holger
Site Admin
Posts: 3231
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Wed Jan 11, 2006 8:37 pm

> Directly read the data its the prefered method.

Yup, also think that... :-)

> Transparent zip support is now implemented - so far.
> But reading PCX or WAV,MOD file is 'given' to the SDL-routines.

There are SDL functions to read from a pointer to a memory buffer instead of a file -- I assume that using them should work fine (although the corresponding function for SDL_mixer seems to be hidden and must explicitly be declared in your own code for some strange reason; maybe it's not yet official (but maybe this already has changed in the last stable version of SDL_mixer; haven't checked that for some time)).

> Any way to load the data and give a pointer to the SDL-routines.

Yep, that's exactly what SDL offers. See www.libsdl.org!

> I dont want to rewrite the SDL/X11 lib for zip support.

Yeah, sure... ;-)

It will only work for the SDL version, though, but I think we could live with this, as the X11 version has some other limitations, too, like no music or no fullscreen support...

> Should the access thread save (e.g for music ) ?

No idea... It probably doesn't hurt if it is... ;-)

> Write to zip files not supported - Necessary? I think no.

Nah! Only reading should be just fine! :-)

> And the main question: What tab indent do you use?
> I prefer "tabs converted to spaces" indent = 2.

Just see in the source code: I use "real tabs" with the equivalent size of eight spaces and an indentation of two characters when editing C source. :)

> If you want I can send you the source (before I do this I have to tidy up my
> changes).

Yes, of course! :-)

Although I can't promise instantly adding it (too many other TODOs that I think are currently more important), but I will happily have a look at your code and maybe add your changes if I think that they fit nicely into the current code base. :-)

(Where it is perfectly OK if that code base is 3.1.1 even if there were quite some changes since then -- most changes should not affect your zip file access changes anyway...)

Post Reply