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

Mocha Doom v1.4 is out [well, now 1.4a]

Recommended Posts

...and this time, it's fully playable. It has also been almost exactly one year since I started this project, so this is also Mocha Doom's birthday, in a way.

- Fixes since v1.31: -

  • SPEED throttling added (at last!) and now it's perfectly playable at a normal speed.
  • Renderer visual glitches fixed, and now rendering is full-quality without the
    "mini-HOMs" in the render.
  • Selectable resolutions (only multiples of 320 x 200, for now).
  • New .bat file, usable with ZDL and CDL for warping and iwad choosing.
  • Scaling of fixed graphics (menus, titlescreen, etc.) is almost 100% complete.
  • Improved, cross-OS mouse handling code.
  • Fixed an issue which prevented the window from popping up in several linux distros.
  • Fixed canvas/window alignment problems on different platforms.
  • Ability to save and load vanilla doom games, and reconstruct infighting targets from stored raw pointers.
  • Support for all major IWADs, now they should all be playable start-to-end.
  • Proper finale and handling of secrets/intermissions/finales according to IWAD.
  • Weapons flash issue fixed.
  • Status bar and HUD fully functional and scalable.
  • Wiper effect now works properly and at scalable speed.
  • Added -fastdemo, -fasttic, +map command line parameters support.
  • Automatic detection of Ultimate Doom in doom.wad filename.
  • Some support for XBLA doom (xbla.wad is an acceptable IWAD name).
It's perfectly possible to play all IWADs start-to-end, save your progress, load it back, and even revisit some of your older saved vanilla Doom games, but this time with a twist: infighting targets will be reconstructed ;-)

Read the README.TXT file for all the new features, as well as the new command-line switches, that for the first time allow you to choose between the two different renderers, and select different resolutions (only multiples of 320 x 200, for now, with default at 960 x 600).

Not much more to say, grab it and play the hell out of it :-)

Share this post


Link to post

My mouse jumps out the window a lot. More easily through the bottom of the window and if the mouse is moved fast. Problem gets worse if I lower the sensitivity. (Windows 7 and Xubuntu 11.04)

Loading wads resulted in an empty black window until I realized I needed to press enter in the console. Can be a little confusing.

Share this post


Link to post

Oh awesome, I've been waiting for this!

But unfortunately, I'm getting an error every time I try to load the main batch file:

C:\Documents and Settings\Owner\Desktop\mochadoom-techdemo-14>cd C:\Documents an
d Settings\Owner\Desktop\mochadoom-techdemo-14\

C:\Documents and Settings\Owner\Desktop\mochadoom-techdemo-14>java -cp C:\Docume
nts and Settings\Owner\Desktop\mochadoom-techdemo-14\\mochadoom.jar i/Main
Exception in thread "main" java.lang.NoClassDefFoundError: and
Caused by: java.lang.ClassNotFoundException: and
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: and. Program will exit.

C:\Documents and Settings\Owner\Desktop\mochadoom-techdemo-14>pause
Press any key to continue . . .


However this doesn't happen when I load the benchmark batches and they run just fine. Not sure if anyone else is getting this but I've never had this problem before.

Share this post


Link to post

@Triple_sSs:

Fixed. It's the spaces in the filenames. You can fix this yourself by changing mochadoom.bat to:

cd %~dp0
java -cp "%~dp0\mochadoom.jar" i/Main %*
pause
(notice the extra quotes). This solved the path problems for me, and amended that in the main download. Thanks for catching this! The spinners were unaffected because they didn't use that %~dp0 variable for forcing the execution directory.

@RRandy87:

Yes, I'm aware it's not perfect. Unfortunately mouse input behaves very differently under different platforms, in terms of movement speed, acceleration, and even parsed inputs through AWT, despite the "write one, run anywhere" promise.

E.g. it worked great under XP, Mac OS Snow Leopard and Ubuntu, while Debian Lenny gave me extreme jerkiness like the one you described. The only solution is having different mouse "drivers" (or rather, listeners) around and allowing the user to plug them in/out with command line args or something similar. Under XP, I had to set the mouse speed (or the mouse DPI) to a higher amount than on Ubuntu, to keep it from leaving the window too often.

Now for a solution: I added a forced grabbing switch (-grabmouse) to be added at command-line, which warps the mouse back even if it wandered outside the main screen area. It's more aggressive than the previous method, try that and see what happens (should I make it the default behavior?). In the new download I added two modified startup script files (mochadoom-grabmouse.bat and .sh) which force this behavior by default. I didn't change version numbers for this, just amended the problem and added a note in the readme.

Share this post


Link to post

Tried out the new grabmouse change and it seems to have solved the problem. I can still see it leave the window if i give the cursor a yank, but it doesn't seem effect gameplay. As for if it should be the default behavior, I guess that depends on if the problem is widespread or not. And of course, great work on Mochadoom!

Share this post


Link to post

Sorry, but how do I run this? I've double clicked everything! :P
I've put my Doom.wad in the same folder. Thanks in advance. :)

Share this post


Link to post

You should have the Java Runtime Environment installed on your system and in your command path, first of all, preferably the latest version:

http://www.java.com/en/download/index.jsp

Once you have that, if you're on Windows, just clicking on mochadoom.bat or mochadoom-grabmouse.bat should do the trick.

Share this post


Link to post

Thank you. I've just done a reinstall of Win XP and forgot that I hadn't installed JRE. It plays well - great job. :)

Share this post


Link to post
DuckReconMajor said:

maes u r the man

any possibility of novert?



I did a bit more than that: I uploaded a slightly fixed release v1.4a.

In this one, I introduce -novert by default (you can override it by -novert disable if you wish), and, more importantly for folks that have had problem with window focus, mouse grabbing etc., I introduced a new event handling system which should be more robust, but I need to get some cross-platform testing.

To enable the new system, use the -mochaevents command line parameter. It should allow more robust mouse grabbing without interfering e.g. with window moving, and reduce jerky response
and jitter.

If the new system works better for most people, I will make it the default from now on. I need testing though, gentlemen, I can only
have access to so many different platforms :-p

The new version:

http://sourceforge.net/projects/mochadoom/files/mochadoom-techdemo-14a.zip/download

The readme entry:

-Fixes since v1.4: -

  • Added a new event system which should be much friendlier, gameplay and OS wise. use the -mochaevents command line parameter to activate it.
  • Added -novert by default.
-mochaevents : introduced in v1.4a, it uses a different
               event handling system which should work
               more smoothly than the default one.

-novert [disable] : by default, vertical mouse movement for
                    the player will be disabled, unless you
                    use the -novert disable command.

Share this post


Link to post

Thanks for the fixes, Maes. I finally got it going and you've done a great job! It's finally starting to feel just like good ol' Doom.

Just another minor minor thing I noticed, the up and down arrow keys don't work though left and right ones do. I was still able to play with the WASD keys (and I prefer using them anyways), but it would be nice to have them usable.
Once again, keep up the good work! =)

Share this post


Link to post
Triple_sSs said:

Just another minor minor thing I noticed, the up and down arrow keys don't work though left and right ones do. I was still able to play with the WASD keys (and I prefer using them anyways), but it would be nice to have them usable.
Once again, keep up the good work! =)


Thank you for all your kind words :-)

The key issue is inevitable ATM as I can only map one key to one action, vanilla style, and it's one of those points where i usually start pulling Boom and ZDoom stuff into the codebase (and first of all I need a much more flexible console/global vars system). Well, there surely is always room for improvement ;-)

Share this post


Link to post

Today I've implemented parallel rendering in prboom-plus. I start two additional threads: for walls and for flats, but they work one after another, not simultaneously. How does it work in Mocha Doom?

Timedemo on dv.wad at 640x480 on Pentium Dual-Core:
serial: 490 fps
parallel: 548 fps

~10%

Thanks Nicholai Main for new music engine without SDL_mixer and its crashes on multicore systems.

Share this post


Link to post
entryway said:

Today I've implemented parallel rendering in prboom-plus. I start two additional threads: for walls and for flats, but they work one after another, not simultaneously. How does it work in Mocha Doom?


I create 2 + 1 by default instead, but any amount can be chosen.
They all start together. This is possible because first I complete the BSP traversal, which populates the visplanes but WITHOUT drawing the walls immediately (DrawSegs is not called immediately upon a node end).

Instead, I enqueue a series of "wall rendering instructions" (RWIs) into a memory pool, and later I fire both types of threads together, and they join the main thread together, just before sprite drawing.

You can picture this as serial BSP -> Drawseg calls -> RWIs stored -> parallel walls + flats.

Well, all of this is in the CVS code anyway. In theory it should be more cache-efficient to avoid mixing the BSP/DrawSegs code with the column rendering one by postponing the drawing, even with a serial renderer.

Each RWI actually stores instructions for rendering a single column, so you need to issue at least as thrice as many as the screen width, but often more than that, so their array needs to be resizable, as you don't know how many you might need to render. The wall threads "see" the list and are assigned equal portions of it before being forked, same with the floor threads (they are assigned visplanes equally).

It should be possible to construct whole-wall rendering instructions instead, at the cost of increased complexity, and then assign whole-walls between the threads. Kinda like a poor man's polygon engine ;-)

The speedup depends on a lot of factors, in primis if your bottleneck is the gameplay code, the video card, etc. In theory it should give larger boosts on higher resolutions with relatively slow videocards and many different visplanes in view, with too low resolutions it's not worth the effort.

Share this post


Link to post

My code:

RenderPlayerView()
{
  WakeRenderer(&smp_segs);
  R_RenderBSPNode (numnodes-1);
  SMP_SetState(1);
  FrontEndSleep(&smp_segs);

  WakeRenderer(&smp_spans);
  R_DrawPlanes();
  SMP_SetState(1);
  FrontEndSleep(&smp_spans);
}


void SMP_ColFunc(draw_column_vars_t *dcvars)
{
  if (!use_smp_segs)
  {
    dcvars->colfunc(dcvars);
  }
  else
  {
    if (smp_segs.count >= smp_segs.size)
    {
      while (smp_segs.index < smp_segs.count)
        SDL_Delay(1);

      smp_segs.size = (smp_segs.size == 0 ? 1024 : smp_segs.size * 2);
      smp_segs.data.segs = realloc(smp_segs.data.segs, smp_segs.size * sizeof(*dcvars));
    }

    smp_segs.data.segs[smp_segs.count] = *dcvars;

    smp_segs.count++;
  }
}

int render_segs_thread_func(void *unused)
{
  while (1)
  {
    // sleep until we have work to do
    RendererSleep(&smp_segs);

    do
    {
      while (smp_segs.index < smp_segs.count)
      {
        smp_segs.data.segs[smp_segs.index].colfunc(&smp_segs.data.segs[smp_segs.index]);
        smp_segs.index++;
      }
    }
    while (SMP_GetState(&smp_segs) != 1);

    while (smp_segs.index < smp_segs.count)
    {
      smp_segs.data.segs[smp_segs.index].colfunc(&smp_segs.data.segs[smp_segs.index]);
      smp_segs.index++;
    }

    SMP_SetState(&smp_segs, 0);
  }

  return 0;
}

// Similar for spans
As I understood, you have something similar, but you draw segs and spans simultaneously

Share this post


Link to post

Yeah it's very similar, although I used a column-level parallelization. Now that I think of it, there's nothing preventing me from doing two drawseg traversals: a quick one that computes only the visplane borders and the drawseg parameters, and then have the threads work on the already parametrized drawsegs, just like you do.

here's the infamous "RWI" which should be properly be "RenderColumnInstruction":

/** This is all the information needed to draw a particular column. Really.
 *  So if we store all of this crap somewhere instead of drawing, we can do the
 *  drawing when it's more convenient, and since they are non-overlapping we can 
 *  parallelize them. Any questions?
 *  
 */

public class RenderWallInstruction {    
    int centery;
    int dc_iscale;
    int dc_source_ofs;
    int dc_texturemid;
    int dc_texheight; // Boom enhancement
    int dc_x;
    int dc_yh;
    int dc_yl;
    int[] columnofs;
    byte[] dc_colormap;
    byte[] dc_source;
}
Here's the RenderPlayerView code:
public void RenderPlayerView (player_t player)
{   
  // Clear buffers. 
  MyBSP.ClearClipSegs ();
  MyBSP.ClearDrawSegs ();
  MyPlanes.ClearPlanes ();
  MyThings.ClearSprites ();
  DGN.NetUpdate ();
  // No rendering is being done here, only visplane 
 //  border computations, which are lightweight anyway.
  // and RWI pipelining
  MyBSP.RenderBSPNode (LL.numnodes-1);
  // This starts BOTH walls and floor threads, since we
  // have complete information for both.
  RenderRWIPipeline();
  DGN.NetUpdate ();
  MyPlanes.DrawPlanes ();
  
  try {
  // All threads (plus main) sync up here
    visplanebarrier.await();
} catch (Exception e){
    e.printStackTrace();
}

  DGN.NetUpdate ();  
  MyThings.DrawMasked ();    
  DGN.NetUpdate ();           
}
Here's how one of the wall rendering threads looks:
public class RenderWallExecutor implements Runnable, IVideoScaleAware {
    
    private CyclicBarrier barrier;
    private RenderWallInstruction[] RWI;
    private int[] ylookup;
    private byte[] screen;
    private int start, end,numthreads=1;
    
    public RenderWallExecutor(int[] ylookup, byte[] screen, RenderWallInstruction[] RWI, CyclicBarrier barrier){
        this.ylookup=ylookup;
        this.screen=screen;
        this.RWI=RWI;
        this.barrier=barrier;
    }
    
    public void setRange(int start, int end){
        this.end=end;
        this.start=start;
    }
    
    public void setRange(int start, int end,int numthreads){
        this.end=end;
        this.start=start;
        this.numthreads=numthreads;
    }
    
    public void run(){

        int centery;
        int dc_iscale;
        int dc_source_ofs;
        int dc_texturemid;
        int dc_x;
        int dc_yh;
        int dc_yl;
        int dc_texheight;
        int[] columnofs;
        byte[] dc_colormap;
        byte[] dc_source;

        //System.out.println("Wall executor from "+start +" to "+ end);
        
        for (int i=start;i<end;i++){
        
        // Copy shit over from current RWIs...     
        centery=RWI[i].centery;
        dc_iscale=RWI[i].dc_iscale;
        dc_source_ofs=RWI[i].dc_source_ofs;
        dc_texturemid=RWI[i].dc_texturemid;
        dc_x=RWI[i].dc_x;
        dc_yh=RWI[i].dc_yh;
        dc_yl=RWI[i].dc_yl;
        dc_texheight=RWI[i].dc_texheight;
                
        columnofs=RWI[i].columnofs;
        dc_colormap=RWI[i].dc_colormap; 
        dc_source=RWI[i].dc_source;
        
        int              count; 
        int dest;            // killough
        int  frac;            // killough
        int fracstep;     
        
        count = dc_yh - dc_yl + 1; 

        if (count <= 0)    // Zero length, column does not exceed a pixel.
          continue; 
                                       
        // Framebuffer destination address.
        // Use ylookup LUT to avoid multiply with ScreenWidth.
        // Use columnofs LUT for subwindows? 

        dest = ylookup[dc_yl] + columnofs[dc_x];  

        // Determine scaling, which is the only mapping to be done.

        fracstep = dc_iscale; 
        frac = dc_texturemid + (dc_yl-centery)*fracstep; 

        // Inner loop that does the actual texture mapping,
        //  e.g. a DDA-lile scaling.
        // This is as fast as it gets.       (Yeah, right!!! -- killough)
        //
        // killough 2/1/98: more performance tuning

        {
          final byte[] source = dc_source;       
           final byte[] colormap = dc_colormap; 
          int heightmask = dc_texheight-1;
          if ((dc_texheight & heightmask)!=0)   // not a power of 2 -- killough
            {
              heightmask++;
              heightmask <<= FRACBITS;
                
              if (frac < 0)
                while ((frac += heightmask) <  0);
              else
                while (frac >= heightmask)
                  frac -= heightmask;
                
              do
                {
                  // Re-map color indices from wall texture column
                  //  using a lighting/special effects LUT.
                  
                  // heightmask is the Tutti-Frutti fix -- killough
                  
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS))]];
                  dest += SCREENWIDTH; 
                  if ((frac += fracstep) >= heightmask)
                    frac -= heightmask;
                } 
              while (--count>0);
            }
         else
            {
              while ((count-=4)>=0)   // texture height is a power of 2 -- killough
                {
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS) & heightmask)]];
                  dest += SCREENWIDTH; 
                  frac += fracstep;
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS) & heightmask)]];
                  dest += SCREENWIDTH; 
                  frac += fracstep;
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS) & heightmask)]];
                  dest += SCREENWIDTH; 
                  frac += fracstep;
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS) & heightmask)]];
                  dest += SCREENWIDTH; 
                  frac += fracstep;     
                }
              if ((count & 1)!=0)
                  screen[dest] = colormap[0x00FF&source[dc_source_ofs+((frac>>FRACBITS) & heightmask)]];
            } 
        }
        }
        try {
            barrier.await();
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (BrokenBarrierException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

    public void updateRWI(RenderWallInstruction[] RWI) {
        this.RWI=RWI;        
    }

}
Yeah, quite a mouthful ;-)
Now I realize that there is no need to pre-split stuff into columns but I can simply pipeline the drawsegs themselves, or a suitable new type of object. It might actually be faster (surelly less memory-intensive).

Share this post


Link to post
Maes said:

although I used a column-level parallelization

What I use then? I put ready for drawing columns into columns list and draw them in thread.

if (mid >= yl)
{
  dcvars.yl = yl;
  dcvars.yh = mid;
  dcvars.texturemid = rw_toptexturemid;
  tex_patch = R_CacheTextureCompositePatchNum(toptexture);
  dcvars.source = R_GetTextureColumn(tex_patch,texturecolumn);
  dcvars.texheight = toptexheight;
- colfunc (&dcvars);
+ dcvars.colfunc = colfunc;
+ SMP_ColFunc(&dcvars);

Share this post


Link to post
entryway said:

What I use then? I put ready for drawing columns into columns list and draw them in thread.


*smacks forehead* lol yeah, I only took a quick glance at the column code, and focused on the RenderPlayerView function instead, and I though that you had used a parallelized version of R_RenderSegLoop which operated on whole drawsegs instead, which was just what I was going to do next. Column-based parallelization is easy in that you just modify what happend instead of calling colfunc();

However, a different approach is possible: parallelizing individual calls to R_RenderSegLoops to avoid creating long lists of instructions in memory. This way, you do not have to deal with the issue of not knowing how many columns may have to be drawn a-priori, as every thread will only draw based on the knowledge of one drawseg and generate the stuff it needs internally.

If you also compute the visplane boundaries in that step, then yeah, you have a blocking relationship between walls and floors and you can't start them together. If you run a "lightweight" R_RenderSegLoop beforehand however, you can start them together with minimal overhead and potentially more parallelization. "Preemtive data dependency removal" they call it in OpemMP/MPI textbooks :-p

Share this post


Link to post

So how do I get the source code?
Trying cvs always crashes for me before getting even a single source file.

Share this post


Link to post

What CVS client are you using?

I am using Eclipse's built-in CVS tool for checking out and committing, using the URL listed here. This approach worked fine on 3 different platforms. Out of stand-alone CVS tools I've only tried CVSTortoise under Windows XP, which also worked just fine.

Ofc if all else fails you can just get the tarball from here:

http://mochadoom.cvs.sourceforge.net/mochadoom/

It's set up as an Eclipse project. If you want to build stuff yourself however, start compilation from src/i/Main.java (this will build everything except unused stuff and testers). Most testers are as of now broken, so don't bother unless you use an IDE.

Share this post


Link to post

Well, if you're into "nightly builds", here are a few new things worth checking out:

  • The version in the CVS actually has sound (music, sfx) but it's still WIP and has several problems (no positioning, sfx volume is not always set, buggy channel reuse/chainsaw and other sounds handling etc.), since David's "driver" was just good enough to plug in and work, but missed all those features
  • I implemented an alternate version of the parallel renderer (ParallelRenderer2) which is seg-based rather than column-based (RenderSegLoop runs once in the main thread without drawing (but computing bounds), and then a reduced version of it runs inside worker threads (RenderSegExecutor, draw stuff but does not recompute bounds), executing stored RenderSegInstruction.
With regards to the latter, in theory, the advantage is that less stuff is pipelined per thread (you pipeline whole segs instead of individual columns) and it might be faster in some scenarios where there is a great field of view with many openings/windows,many short columns and many segs visible etc. but in practice it's a tad slower than the column-based one in simple maps. It should also have an advantage at VERY high resolutions. The tradeoff is that part of the RenderSegLoop computations are done twice (once in the main thread and then split accross worker threads).

Unfortunately, while it doesn't crash or anything it's still visually unstable, because of subtle data dependencies (works mostly OK with one thread, but more than one and ceilings/floors "punch through" textures. Probably the solution is restricting each thread to only process similar rw_start/rw_stop ranges somehow. so that they don't screw up each other's ceiling/floor markings.

Update: it now works stably with any number of threads, drawing priorities are respected etc. but there is still some "jitter" on wall columns (column offsets are unstable).

The work partitioning per-thread is as follows: each thread is assigned a portion of the screen (e.g. 0-639 for thread #1 and 640-1279 for thread #2) and only draws the portions of drawsegs that are contained within its screen area. This solves the concern of keeping floorclip/ceilingclip consistent for similar rw_x values. Also, threads can continue drawing portions of walls that originated in another thread's domain, by applying a proper bias to rw_scale, pixhigh, etc. with continuity, without forming rendering gaps.

This scheme results in more even workload balance, since each thread will draw the same number of pixels as every other. All threads check out ALL "DrawSegInstructions" to determine if they must draw a portion of a particular wall. Of course, if a wall is not contained at all in a certain screen zone, it's not drawn by the responsible thread at all.

Yet another update: fixed the "jitter bug", which was caused by dc_offset contention between threads. Now each thread can request its own without being affected by the deeds of other. After some more optimizations, the two renderers are practically on the par (Ultimate Doom DEMO2 timedemo at 1280x800 Screenblocks 10 is 130 fps parallel (both), 119 fps serial. Now, perhaps in a situation where there are significantly more columns than 3xSCREENWIDTH, the seg-based one may have an edge.

Share this post


Link to post
Porsche Monty said:

I just can't get over the fact that it's allegedly pure java. Simply amazing.

I've compiled it in Eclipse, so it is pure java.

Share this post


Link to post
Randy87 said:

I've installed JDK and Eclipse. How do I go about compiling?


Heh I gotta include a HOWTO in the CVS sooner or later, but really, Mocha Doom is quite simple to build. If you want to build it with just a JDK and no eclipse, unzip the tarball, make sure there's a src folder in there. Create an output folder of your liking (e.g. a .\bin folder at the same level as the .\src one), cd into the src folder and compile everything into bin with:

mkdir bin
cd src
java -d ..\bin i/Main.java
cd ..
and to run it:
java -cp bin i/Main [parameters]
Of course in the distributed versions I make a jar out of all those output files and include some convenience scripts for starting.

This will start compiling from package i, class Main, and will "pull" everything needed with it automatically. Since Mocha Doom is entirely self-contained, for now, there's nothing else to worry about.

In Eclipse, just checking out the CVS (select "Import new project from CVS") or making a new Java project for an existing project (there should be a .project file in the CVS root) or existing source files (using src as a source folder) and letting Eclipse handle the build automatically should be enough, since there are no external dependencies. To run it, create a new Run configuration for i.Main, which also accepts the usual Doom command-line arguments. That's it. No Maven, no makefiles, no JNI, no libraries.

The only part that might be tough to compile without Eclipse, unless you know what you're doing, is the stuff in the testers package, which is not compiled along with the rest by just starting from i/Main.java, since it's not referenced by anything else in the package. These are mostly unit testers for various components (e.g. renderer, sound, wad manager, etc.) but most are largely obsolete and out of sync with the codebase, since they were mostly used in very early development. Most of the stuff in testers will appear redlined in Eclipse for this reason.

Also, there might be some .c and .h files and a few broken/unused .java files here and there, which are not meant to be compiled: they are either residuates I will eventually remove or stuff currently in development. Eclipse will redline them but ignore them, as they are not used in the build itself.

NOTE: as you might have noticed, the current CVS version has sound, along with other goodies. Make sure you have the latest-latest-latest version though, as e.g. just a few days ago, some sound classes used a restricted library which might not compile on every system. I've since removed this dependency.

Share this post


Link to post

Hmm yeah those were left a bit dirty after last night's work. Get the latest CVS build (a few minutes ago)t... or use eclipse instead of manual building, which will skip them.

Edit: I updated the CVS and now it's buildable even by hand. I should really separate development from stable code, huh? ;-)



That warning is normal.

P.S.: what's with all these people having trouble with using/refusing to use CVS and resorting to the tarball? :-/

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
×