Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
cycloid

Built Chocolate Doom with DevCpp

Recommended Posts

I didn't have SDL_Net to hand so had to comment out various parts of i_net.c and i also had to change a couple of include file paths(though upon reflection i could have just added each dir in the source tree to the local includes paths) but it built and ran no trouble for win32.

Next i'm going to attempt an AROS x86 port, and probably even an Amiga 68k back-port - though that will probably just be an excersise in endian-ness and will run dog slow even on an emulator, heh.

anyone else got any CD porting stories / woes to share before i get stuck in?

Share this post


Link to post

This one time I compiled Chocolate Doom I think.

If you don't have SDL_net you should be able to disable multiplayer by uncommenting FEATURE_MULTIPLAYER in doomfeatures.h. I haven't tested the FEATURE_ #defines in ages though, so it might be broken.

Any endianness problems should have been fixed by now, as it's been made to run on Sun and PPC. I assume you're using the latest version from SVN.

Let me know how things go!

Share this post


Link to post

heh, no i've never been able to figure out this CSV / SVN business, too much messing about with fiddley command lines for my liking, i just downloaded the source from the website (quick looksee at CD website, 0.1.4?). At least i got my brother to download it and post it to me as i dont have my net connection set up at home yet.

Share this post


Link to post
cycloid said:

heh, no i've never been able to figure out this CSV / SVN business, too much messing about with fiddley command lines for my liking, i just downloaded the source from the website (quick looksee at CD website, 0.1.4?). At least i got my brother to download it and post it to me as i dont have my net connection set up at home yet.

The 0.1.4 release is almost a year old now, I think. If you're scared of command lines you can try TortoiseSVN. Alternatively, I keep a reasonably up-to-date copy of the SVN version on my site.

Share this post


Link to post

ok, cool, except the shitty firewall at work chokes on .gz files. ho hum. no major rush anyway as like i said i dont have net at home and dont have a CD Writer at work .. life sucks !

Share this post


Link to post
cycloid said:

ok, cool, except the shitty firewall at work chokes on .gz files. ho hum. no major rush anyway as like i said i dont have net at home and dont have a CD Writer at work .. life sucks !

Dude, get a cheap USB pendrive!

Share this post


Link to post

we're not allowed them - security. at my old job i could leave my workstation on all weekend downloading crap and burn it all to CD to take home, an i have gigs of crap archived on CD now, had to put together an access database just to keep track of it all.

anyway, i will get netted up in the next couple o months

as for getting choccodoom to compile i've put the directory structure back the way it was and added some stuff at the start of config.h along the lines of

#define NET_NONE
//(NET_SDL_NET is assumed but not needed to be #defined otherwise)

#define SOUND_NONE
//(SOUND_SDL_MIXER assumed and implied)

so when i get my libs sorted and linking i can just comment out the offending lines. it builds for amiga 68k but does not link, but that's probably something i'm doing with the cross compiler, plus i havent exactly spent hours labouring away at it (yet) only tinkering for like 10 minutes at a time.

Share this post


Link to post

behold:



Still 0.14

Endianness issues seem to be mostly sorted, though the built in SHORT and LONG macros were misaligned (defined as short in one place and unsigned short in another)

Had an issue finding the IWAD - amigaOS doesnt recognise "./" as meaning "local dir" so i had to stick an #ifdef in there

As for the lump issue i know the doom2.wad i'm using is good as my chocdoom_x86.exe resides in the same physical path and works fine. Will need to printf some debug info to follow the lump parsing though i suspect it could still be endian related, any clues?

Share this post


Link to post
cycloid said:

behold: (Screenshot)

Very cool.

As for the lump issue i know the doom2.wad i'm using is good as my chocdoom_x86.exe resides in the same physical path and works fine. Will need to printf some debug info to follow the lump parsing though i suspect it could still be endian related, any clues?

The W_CheckNumForName() function uses some dodgy method of comparing integers to find names. Try replacing that gunk with memcmp().

Share this post


Link to post
cycloid said:

behold:

[Init screen running on AmigaOS]

Still 0.14

Excellent!

Endianness issues seem to be mostly sorted, though the built in SHORT and LONG macros were misaligned (defined as short in one place and unsigned short in another)

This is fixed in the latest SVN version :-)


Had an issue finding the IWAD - amigaOS doesnt recognise "./" as meaning "local dir" so i had to stick an #ifdef in there

Does AmigaOS have an equivalent to this at all?

I recently did some restructuring of the IWAD finding code and I think the superfluous "./" paths are gone now. If not, I'll make sure they go :-)

Ajapted said:

Very cool.

The W_CheckNumForName() function uses some dodgy method of comparing integers to find names. Try replacing that gunk with memcmp().

Yes, 0.1.4 still had this, left over from the original source release. I've since removed it. The PNAMES not found message is consistent with W_CheckNumForName not working properly.

Share this post


Link to post

Chocolate DOOM for AmigaOS???!!!! Unbelievable!!!!!!!!!!!
What requirements will be at it? Only AGA/external videocard?

Share this post


Link to post
cycloid said:

AmigaOS

I demand the Amiga model/Workbench version! Workbench looks like 2.x but the last time I used that was 1994 and I was seven, so my memory is sketchy at best.

I highly doubt my Amiga 500 could ever run it, but...

If you want the latest SVN of chocolate-doom, I could throw up a .lha if I ever find something that can make .lha archives.

Share this post


Link to post

(emulated) A1200 OS3.1, 800x600x16 (picasso96), 32mb fast ram

Adoom does run on a processor/ram expanded A1200, and any amiga specifics will be lifted from that (or adoomppc) source

I've shifted my focus to the 0.2.0 SVN archive fraggle pointed me to, which is a lot more involved (= more clock cycles in use too probably though so maybe i should have stuck to 0.1.4).o disabling the sound (leaving only stub functions) was simple enough but the net portion was a lot more complex. I had clashes between the dedicated/standard code (e.g. two D_Main functions) and so ditched the dedicated support. Also there abbears to be two Zone files, so picked a random one.

Endian issues do seem to be sorted in this one yes

Not managed to build this one yet, though, as i dont have an inttype.h or even a stdint.h will either have to trawl one up or clobber together my own from the PPC includes.


edit: the previous 0.1.4 buld was *******ely parsing (IIRC) 2921 lumps from doom2.wad - which i checked was correct with XWE - but any attempt to printf the names of the lumps prints blank lines so something's going wrong somewhere

anyway, i hope to get this ported to AmigaOS (AGA may be tricky without bombing the source, i'm trying to be gentle with the #ifdefs) and AROS (x86 and PPC - once i get an old mac) which will lay the ground work for MorphOS and AmigaOS 4 (both of which i'm unlikely to be able to run in the forseeable future).

After that then it'll be winmbf and maybe hopefully eventuall eternity.

Share this post


Link to post
cycloid said:

I've shifted my focus to the 0.2.0 SVN archive fraggle pointed me to, which is a lot more involved (= more clock cycles in use too probably though so maybe i should have stuck to 0.1.4).o disabling the sound (leaving only stub functions) was simple enough but the net portion was a lot more complex. I had clashes between the dedicated/standard code (e.g. two D_Main functions) and so ditched the dedicated support. Also there abbears to be two Zone files, so picked a random one.

You should use the z_zone.c file :-)

Endian issues do seem to be sorted in this one yes

Good!



Not managed to build this one yet, though, as i dont have an inttype.h or even a stdint.h will either have to trawl one up or clobber together my own from the PPC includes.

You should just need inttype.h, with something like:

typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
typedef signed int int32_t;
typedef signed short int16_t;
typedef signed char int8_t;


edit: the previous 0.1.4 buld was *******ely parsing (IIRC) 2921 lumps from doom2.wad - which i checked was correct with XWE - but any attempt to printf the names of the lumps prints blank lines so something's going wrong somewhere

Is this still happening now?

Share this post


Link to post

inttypes - thanks for that list, though i've found a more up to date amiga clib havent tried it yet

as for the lump parsing, i wont know until i've built it, hopefully i'll get there tonight. As it is i'm only spending about 10 - 30 mins an evening on this so hardly burning the midnight oil trying to get it going!

Share this post


Link to post

Built 0.2.0 (sans sound and networking)

still had the local path issue but i just stuck -iwad with a full path in to see what would happen next...

did the doom refresh deamon [..............]

conked out with a cybergraphics screenmode error, which probably falls somewhere between SDL and my emulated hardware.

so basically it's getting as far as actually rendering the title graphic but falling over due to external forces, good progress though and it seems to have taken care of the 0.1.4 lump issue

Share this post


Link to post

What are the bare minimum specs?
Can an A2000 with 030 Turbo with 16 MB and 10 GByte HDD do the trick?
I would like to know this before i begin the struggle installing the Buddah Drivers to get my CD-ROM working again. ;)
(Yeah yeah, i ordered a LAN card from Jens Schoenfeld for easier data transfer, but its not here yet. )

Share this post


Link to post

ADoom port based on dosdoom run well on low-end a500, so why this new port can't do?

Yeah, Schoenfeld a MAN! I waiting that new great A600 accel which it promised to Amiga community :)

Share this post


Link to post

no idea what specs would do it as so far it only runs in an amiga emulator with a native VGA screenmode, amiga-sdl supports P96 screenmodes but it'd mean a lot of messing with the source to back port it to AGA. there's a good AGA/CGX port of quake around if you want to check that out and do some source merging yourself (though i havent tried to build that myself) there's also an Amiga Duke port too.

anyway i was hoping to stick with SDL for this (and winmbf if i ever get that far) to keep the code-changes down to the bare minimum but the Amiga/AROS SDL libs appear to be lacking and i'm just not interested in writing my own wrappers. All this doom porting work is really just a way for me to ease into full blown AOS/AROS dev (i have a filemanager in mind) so i'm not too interested in bending over backwards to get ChocDoom ported i just don't haev the spare time (wife,two kids,full time job)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×