porting super8

Would any Linux and/or Mac coder care to port Super8? This Windows software engine project is pretty much "done". It would be nice to make it available to other OS and should be fairly simple as porting goes.

also, engoo needs porting

i don't mean to hijack, but if super8 gets ported i'll port its ported stuff over

you probably are asking for a SDL 1.2 backend put to it. I have no idea how to do that so good luck!

Would any Linux and/or Mac coder care to port Super8? This Windows software engine project is pretty much "done". It would be nice to make it available to other OS and should be fairly simple as porting goes.

Post most recent source code link and I'll look at it. OS X and Windows engine builds really do not have many differences. I wouldn't be doing the Linux, just the OS X.

(It'd be native OS X, not SDL. Btw. I am not familiar with how SDL would interact with a software renderer, so I wouldn't want to go there. Unless you have something unusual going on, I can't see this taking more than an hour or 2 for me do because I've ported Quake engines to OS X or some other OS like 10 times now and I'd just merge in the input/sound/screenshot/keyboard code from the native Fruitz of Dojo port.)

also, engoo needs porting

I know you'd prefer an SDL port (but I have no idea how SDL works with a software renderer and I think it would take a lot of time --- like more than I have --- to figure that out), but I could port Engoo to OS X native at the same time as super8.

But I haven't been able to get an SVN client to be able to download from your archive. I tried it last year to look at your HLBSP to 256 Quake palette code and I wasn't able to get Tortoise SVN to work with your archive. And the http version doesn't have a "download a tarball" link at the bottom.

If you can make a zip or some such thing of your source (tar.gz or whatever), I'll convert your engine too for OS X. Sure it won't be SDL so it won't help for a Linux build.

Thanks, current snapshot:
http://qbism.com/_extfiles/qbismsrc-12-04-11.zip

Feel free to hijack, and I don't care about SDL one way or the other. Maybe Engoo svn is http://mancubus.net/svn/hosted/fsfps/tnq

but I have no idea how SDL works with a software renderer

.........

there is no rule that sdl only works with accelerated, gl renderers

however one thing you DON'T WANT TO DO is porting the input code to use sdl - it's a trainwreck, yet SDL lovers do it anyway despite the problems that come with it, since numberofplatformssupported > compatibility, responsiveness, usability

there is no rule that sdl only works with accelerated, gl renderers

I agree with that, but I'm not familiar with the mechanics of how to do that with SDL and that would require some planning and testing that exceeds the amount of free time I have available

I always have a couple of hours to throw around, but not necessarily a couple of days. If you know what I mean.

I have Super8 compiling ... but ... I was afraid with a software renderer something like this might happen ...

  Code:

   while (pwedge->u > pedge->u)
      {
         pwedge = pwedge->prev;
      }

On startup, the screen refreshes maybe 20-30 frames of demo1 of times and then the above code does a "Program received signal: EXC_BAD_ACCESS".

I'd assume it is trying to write a pixel outside the buffer (seems like a reasonable assumption, but this might not be right.)

Ideas?

[I don't have any issues with a standard Fruitz of Dojo "WinQuake" running after that is compiled. I did implement the min_vid_width change and setting the warp width to vid.width. Now I would assume you have a fully function Flash version of Super8. Perhaps there is the GDB compiler option it is using to prevent this happening or handle it in a certain way? I'm just throwing ideas out there ... (that doesn't seem likely) ... yet I would assume this is occurring in both the Flash and Windows builds of Super8 but something is "handling it". ]

ADD:

I think drawing any conclusions from the above is premature. I just noticed a number of #ifdef _WIN32 blocks that appear to have the meaning "If this isn't Flash Quake" rather than specific to Windows. I'll have to look through those. I would imagine that almost all of them in a r_whatever.c file really should be "#ifndef FLASH" ... I'll look at those and adapt it.

I reviewed all the #ifdef _WIN32 entries in Super8, only a few needed to be changed to "#ifndef FLASH". Still I get the same error.

I don't know the relevance of this, but up the call stack is something flagged with a warning "Signed shift result (0x7D0000000) requires 36 bits to represent, but 'int' only has 32 bits"

  Code:

// FIXME: do we need this now that we clamp x in r_draw.c?
   edge_sentinel.u = 2000 << 24;      // make sure nothing sorts past this

^^^ Line with warning

   edge_sentinel.prev = &edge_aftertail;


I don't claim to know that much about the inner workings of a software renderer and spans, so I am just speculating on potential causes of what is causing the crash and communicating what I can to describe what is going on. The engine doesn't crash until a demo starts or a map is played, it can display the console just fine.

Now I am just running the engine ... it is imperative to have some external media like a pak10.pak for proper operation of Super8? (I did try to download the engine off the QExpo page but get a 404 .... http://qbism.com/_extfiles/qbismS8-bigmap-06-19-11.zip = not found).

On startup, the screen refreshes maybe 20-30 frames of demo1 of times and then the above code does a "Program received signal: EXC_BAD_ACCESS".

I did a **very** quick'n'dirty linux build of this thing (no networking, no sound, no cdaudio, etc). After cleaning a couple of compile errors (menu.c: line #1018: Cvar_SetValue() for teamplay and coop must use strings not pointers to the cvars; r_sky.c: around line 105: the linux ifdef'ed sprintf() calls must be changed to snprintf()) I've get no segfaults so far. However the behavior may change with the gcc version used, and there's a good chance that if you change localmodels array of sv_main.c from [5] to at least [6] (8 is better), your crash might just disappear: with MAX_MODELS being raised to something with more than 4 digits, that array is the source of many problems, which is an evil & ugly Fitzquake-0.85 bug.

Flash build: Yes, is working.

Need pak? : I should really redirect the download link from qexpo. The latest exe is here http://qbism.com/nexus/wp-content/uploa ... 8_0041.zip
It does include a pak, with a default skymap texture, quake.rc, and watervis data for standard maps. It *should* run without it. I'll try running without the pak when I can get to my dev machine.

Span overruns: It's probably just as likely that some array elsewhere is being overrun into it, since the error is not on all platforms. I will also look at localmodel arrays. If this or similar array is being overrun, it may happen to be harmless on one platform or compiler but destructive in another.

BTW, just got a segfault during demo2: only happens when one goes underwater, therefore it only happens when r_waterwarp is on. The source seems to have played with the MAXWIDTH and MAXHEIGHT macros which are *most likely* the root cause, i.e. changes heeded elsewhere are possibly missed.

Just to add ... I get the same crash with or without the pak8888.pak.

EXC_BAD_ACCESS: Tried increasing the hunk with -heapsize? Running out of hunk should exit gracefully in the engine, though. I don't have vanilla source handy but I compared the function where error was reported (R_StepActiveU) with QIP Quake. It's identical. Not a surprise, since the point of crash is not necessarily the source of the error.

As a reality check, I made a fresh Flash build w/ shareware pak: http://qbism.com/_extfiles/qbS8demo.html but unfortunately it didn't crash.
I tried it with (and without) localmodels set to 8 and it worked either way. I'll leave it at 8.

warpwidth and height are set to video resolution rather than original constants of 320 and 200. This is in R_RenderView:

  Code:

   warpbuffer = Q_malloc(abs(vid.rowbytes)*vid.height); //qbism added abs for possibly negative rowbytes.


However, the "abs" is likely not required anymore. I removed it and jumped in some water, no crash.