Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351307 views, last view: 12/09/2021 06:26

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#1469: Re: can't play Sauerbraten

by eihrul on 06/01/2006 23:04, refers to #1468

20 FPS = mostly unplayable.

reply to this message

#1470: Re: can't play Sauerbraten

by Passa on 06/01/2006 23:32, refers to #1469

Yes, but good enough for mapping, trust me, alot of pgdm was done on that laptop ;)

reply to this message

#1471: startup map

by MeatROme on 06/01/2006 23:36, refers to #1465

when I posted that snippet it was of course not "complete" ...
... what I did was (more or less) the following :

a variable "loadmap" exists and is filled with "curvedm" by default, the snippet would change that in case the user passed a parameter like +maard3 to "aard3"
then the cc->changemap(loadmap) call will work as desired.

placing the calls in autoexec.cfg will not work because they are loaded and executed BEFORE the initial map change, you might even notice two lines at the start of the engine telling you about the gamemode ffa/default - because first it loads an empty map and then the initial map ...

reply to this message

#1472: Re: can't play Sauerbraten

by Max of S2D [Fr] on 06/02/2006 07:32, refers to #1469

"20 FPS = mostly unplayable."

Nope. It's playable, but it disturb.

reply to this message

#1473: Re: Slice snippet

by Passa on 06/02/2006 07:32, refers to #1472

Nice stuff, good work.

Any timeframe on the next SliceTC release?

reply to this message

#1474: ..

by Greywhind on 06/02/2006 22:51

I play with 10-20 FPS all the time - it's perfectly playable.

Hopefully, however, I'll be able to get more than that when I get a new computer sometime this year.

reply to this message

#1475: Re: ..

by absinth on 06/03/2006 02:59, refers to #1462

>I see that fullscreen shaders are now working portably/properly (at least on osx/ATIx800), well done.

how did you get it to compile at all? with current CVS i have problems related to opengl functions pointers:

1. different naming, e.g. PFNGLGENPROGRAMSARBPROC/glGenProgramsARBProcPtr

2. it seems on macosx you can't mix and match function pointers and "normal calls", it seems like it's an all or nothing thing...

3. using the sauerbraten supplied glext.h to circumvent these problems seems like a very bad idea

reply to this message

#1476: Re: ..

by Aardappel_ on 06/03/2006 04:02, refers to #1475

3. why? if your compilation problems come from using some macosx modified version of glext.h, that would be a bad idea. The version of glext.h is the latest official one from SGI, it is included specifically to avoid compilation incompatabilities.

reply to this message

#1477: Re: ..

by guest57 on 06/03/2006 12:41, refers to #1475

My currrent 'solution' is to edit pch.h and hardcode the extension - yuck.

//#define NO_SDL_GLEXT
#include <SDL_opengl.h>
#define GL_TEXTURE_RECTANGLE_ARB 0x84F5

-- aka rpointon

reply to this message

#1478: My attempt to reenable and fix /savegame and /loadgame

by xoltra on 06/03/2006 23:48

I found that /savegame and /loadgame pretty much works for a given instance of sauer_client. Rearranging things a bit so that it does not save any pointers or references makes it work correctly, as far as I can tell (except for some minor stuff such as monsters not remembering they were int the middle of infighting with a fellow monster).

My patch is at the end of my patch page:
http://home.austin.rr.com/selliott4/sauerbraten/

reply to this message

#1479: Re: CVS access

by xoltra on 06/04/2006 00:44, refers to #1477

Try again. It seems to be working now (2006-06-03).

reply to this message

#1480: Re: ..

by absinth on 06/04/2006 01:57, refers to #1476

>The version of glext.h is the latest official one from SGI, it is included specifically to avoid compilation incompatabilities.

hmmm i was just under the impression that using the SGI header file but apple's opengl runtime could cause very nasty problems. if you tell me this can't possibly make problems i'm glad to use this "workaround".

btw. what is the reason that we don't use the glext definitions from SDL_opengl.h (i.e. #define NO_SDL_GLEXT)

reply to this message

#1481: ..

by absinth on 06/04/2006 02:15

>i was just under the impression that using the SGI header file but apple's opengl runtime could cause very nasty problems.

forget my rambling, it seems we have already always done so

also, with cvs trunk the compilation problems seem to have gone away too

reply to this message

#1482: Re: ..

by eihrul on 06/04/2006 16:23, refers to #1480

The definitions in SDL_opengl.h are ancient, i.e. it did not have any support for texture_rectangle.

reply to this message

#1483: ..

by absinth on 06/04/2006 16:33

>The definitions in SDL_opengl.h are ancient
SDL 1.2.10 fixes that

reply to this message

#1484: Re: ..

by eihrul on 06/04/2006 16:50, refers to #1483

Still better to include our own, just so we don't have to force people to use the most recent versions of SDL, and so we can be sure its up to date.

reply to this message

#1485: Message censored by administrator

by Passa on 06/07/2006 08:08

#1486: echo []

by nieb on 06/07/2006 21:57

Could you add a value to echo that lets you set the text color of the echo

echo [door opened!] N;
N = 0-15
being the 16 basic colors

Anyways this would be nice for SP.

reply to this message

#1487: windows stacktraces

by Aardappel_ on 06/07/2006 23:59

From now on, when sauer crashes, it will give a proper stacktrace on windows. Be sure to copy that when you report any sauer crash.

reply to this message

#1488: ..

by Stern on 06/08/2006 21:58

Haha it's funny watching you all talk about running it with 10-20 fps. I was running Cube1 with 250ish fps, and probably a similar number for Cube2. Then again, my computer is amazing... :)

reply to this message

   Board Index