cadcdev-kallistios — KallistiOS related mailing list

Re: [KOS] Is this mailinglist also for beginners?

[Joachim J. <Joa...@lu...>]

Dan Potter wrote:

> The rest looks ok to me. On the textures looking wrong, did you mean
> that they actually look incorrect, or that they are rotated wrong? I'm
> not sure that I matched the texture system of GL so the rotation
> problems might happen. If it's the other, then the first thing is to
> make sure that it's a power of 2 in size. If it's not, then there might
> be a bug (send me the PCX file and I'll take a look).

They look incorrect. I don't know, if the rotating is right, I didn't get actually

to that point but I will inform you if that is wrong.
The textures has a size of 160x160 and were created with "the Gimp" as
PCX-files.

Re: [KOS] Is this mailinglist also for beginners?

[Paul B. <pb...@ax...>]

I started to look into the glOrtho problem myself since I saw that the KGL 
version was not working.  I did some web research and found a pdf article 
that explains the mathmatics behind an othrogonal projection matrix.  I then 
checked out the Mesa3d source and saw that it was using the same math.  I 
tried plugging it into KGL glOrtho and get odd results.  I was planning on 
spending some time this weekend studying the differences between KGL and Mesa 
to why that might be.

I'll blast the PDF to you for your enlightenment.

Paul Boese
pb...@ax...

On Wednesday 28 November 2001 08:20 pm, you wrote:
> On Nov 29, Joachim Jaeckel wrote:
> > I started to create a small gl-program, which shows a cube, zooming from
> > the distance to the front, starts to rotate to show me all his 4 textured
> > faces. The zooming works fine, untill to the point, where the cube should
> > start to rotate. At this point, my code to do the rotating seems to have
> > no effect. Additionally the texturing seems to be wrong... Nearly the
> > same program works fine (without texturing) under Mesa on FreeBSD.
> >
> > Maybe you can have a look in my attached source and point me to my
> > mistakes?
>
> Yeah. I think I see why it's not working, and this might point to an
> important difference between KGL and the spec. Someone more versed in GL
> will have to say for sure... comments below.
>
> > #include <kos.h>
> > #include <GL/gl.h>
> > #include <GL/glu.h>
> >
> > /* the textures for the intro-cube */
> > GLuint	texture;
> >
> > int zoom = -100; /* the counter for zooming the cube */
> > GLfloat yrot = 0.0f;
> >
> > void cube() {
> >
> > 	glTranslatef(0.0f, 0.0f, (zoom * 1.0f));
> >
> > 	glBegin(GL_QUADS);
> > 		/* First face */
> > 		glBindTexture(GL_TEXTURE_2D, texture/*1*/);
> > 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 0.0f);
> > 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 0.0f);
> > 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 0.0f);
> > 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 0.0f);
> >
> > 		/* Second face */
> > 		glBindTexture(GL_TEXTURE_2D, texture/*2*/);
> > 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 0.0f);
> > 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 1.0f);
> > 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 1.0f);
> > 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 0.0f);
> >
> > 		/* Third face */
> > 		glBindTexture(GL_TEXTURE_2D, texture/*3*/);
> > 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 1.0f);
> > 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 1.0f);
> > 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 1.0f);
> > 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 1.0f);
> >
> > 		/* Fourth face */
> > 		glBindTexture(GL_TEXTURE_2D, texture/*4*/);
> > 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 1.0f);
> > 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 0.0f);
> > 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 0.0f);
> > 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 1.0f);
> > 	glEnd();
> >
> > 	glTranslatef(0.0f, 0.0f, 0.5f);
> > 	if (zoom >= -3)
> > 		glRotatef(yrot-=0.01f, 0.0f, 1.0f, 0.0f);
> >
> > 	glTranslatef(0.0f, 0.0f, (zoom * -1.0f - 0.5f));
>
> Ok, here's why your zooms and translates don't work: they are being done
> after the vertex submission. I think even in the regular GL this would
> happen because the transformations only happen to vertices after the
> glTranslatef(), glRotatef(), etc.
>
> > 	if (zoom < -3) zoom++;
> > }
> >
> > /* Load a texture using pcx_load_texture and glKosTex2D */
> > void loadtxr(const char *fn, GLuint *txr) {
> > 	uint32 txaddr;
> > 	int w, h;
> > 	if (pcx_load_texture(fn, 1, 0, &txaddr, &w, &h) < 0) {
> > 		printf("can't load %s\n", fn);
> > 		return;
> > 	}
> >
> > 	glGenTextures(1, txr);
> > 	glBindTexture(GL_TEXTURE_2D, *txr);
> > 	glKosTex2D(GL_RGB565_TWID, (GLsizei) w, (GLsizei) h, txaddr);
> > }
> >
> > extern uint8 romdisk[];
> > int main(int argc, char **argv) {
> > 	cont_cond_t cond;
> > 	uint8	c;
> > 	int i;
> >
> > 	/* Initialize KOS */
> > 	kos_init_all(THD_ENABLE | IRQ_ENABLE | TA_ENABLE, romdisk);
> >
> > 	printf("gltest beginning\n");
> >
> > 	/* Get basic stuff initialized */
> > 	glKosInit();
> > 	glMatrixMode(GL_PROJECTION);
> > 	glLoadIdentity();
> > 	gluPerspective(30.0f, 640.0f / 480.0f, 0.1f, 100.0f);
> > 	glMatrixMode(GL_MODELVIEW);
> > 	glEnable(GL_TEXTURE_2D);
> >
> > 	/* Load the textures */
> > 	//loadtxr("/rd/title.pcx", &texture1);
> > 	//loadtxr("/rd/created.pcx", &texture2);
> > 	//loadtxr("/rd/kalist.pcx", &texture3);
> > 	loadtxr("/rd/copyr.pcx", &texture);
> >
> > 	c = maple_first_controller();
> > 	while(1) {
> > 		for (i = 0; i < 1000; i++){
> > 		}
> >
> > 		/* Check key status */
> > 		if (cont_get_cond(c, &cond) < 0) {
> > 			printf("Error reading controller\n");
> > 			break;
> > 		}
> > 		if (!(cond.buttons & CONT_START))
> > 			break;
> > 		if (!(cond.buttons & CONT_DPAD_UP))
> > 			break;
> > 		if (!(cond.buttons & CONT_DPAD_DOWN))
> > 			break;
> > 		if (!(cond.buttons & CONT_DPAD_LEFT))
> > 			break;
> > 		if (!(cond.buttons & CONT_DPAD_RIGHT))
> > 			break;
> > 		if (!(cond.buttons & CONT_A))
> > 			break;
> >
> > 		/* Begin frame */
> > 		glKosBeginFrame();
> >
> > 		/* Handle the cube */
> > 		glLoadIdentity();
> > 		cube();
> >
> > 		/* Finish the frame */
> > 		glKosFinishFrame();
> > 	}
> >
> > 	return 0;
> > }
>
> The rest looks ok to me. On the textures looking wrong, did you mean
> that they actually look incorrect, or that they are rotated wrong? I'm
> not sure that I matched the texture system of GL so the rotation
> problems might happen. If it's the other, then the first thing is to
> make sure that it's a power of 2 in size. If it's not, then there might
> be a bug (send me the PCX file and I'll take a look).
>
> As a side point, does anyone know if it's valid in GL to do ortho mapped
> graphics by simply doing a glLoadIdentity() on the PROJECTION matrix?
> I'm doing that in the project I'm working on now to do 2D graphics
> without having to use TA primitives, but I don't know if it's portable
> or not.
>
> _______________________________________________
> Cadcdev-kallistios mailing list
> Cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

-- 
Paul Boese
pb...@ax...

Re: [KOS] Is this mailinglist also for beginners?

[Dan P. <ba...@al...>]

On Nov 29, Joachim Jaeckel wrote:

> I started to create a small gl-program, which shows a cube, zooming from the
> distance to the front, starts to rotate to show me all his 4 textured faces.
> The zooming works fine, untill to the point, where the cube should start to
> rotate. At this point, my code to do the rotating seems to have no effect.
> Additionally the texturing seems to be wrong... Nearly the same program works
> fine (without texturing) under Mesa on FreeBSD.
> 
> Maybe you can have a look in my attached source and point me to my mistakes?

Yeah. I think I see why it's not working, and this might point to an
important difference between KGL and the spec. Someone more versed in GL
will have to say for sure... comments below.

> #include <kos.h>
> #include <GL/gl.h>
> #include <GL/glu.h>
> 
> /* the textures for the intro-cube */
> GLuint	texture;
> 
> int zoom = -100; /* the counter for zooming the cube */
> GLfloat yrot = 0.0f;
> 
> void cube() {
> 
> 	glTranslatef(0.0f, 0.0f, (zoom * 1.0f));
> 
> 	glBegin(GL_QUADS);
> 		/* First face */
> 		glBindTexture(GL_TEXTURE_2D, texture/*1*/);
> 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 0.0f);
> 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 0.0f);
> 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 0.0f);
> 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 0.0f);
> 
> 		/* Second face */
> 		glBindTexture(GL_TEXTURE_2D, texture/*2*/);
> 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 0.0f);
> 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 1.0f);
> 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 1.0f);
> 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 0.0f);
> 			
> 		/* Third face */
> 		glBindTexture(GL_TEXTURE_2D, texture/*3*/);
> 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(0.5f, -0.5f, 1.0f);
> 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 1.0f);
> 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 1.0f);
> 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(0.5f, 0.5f, 1.0f);
> 
> 		/* Fourth face */
> 		glBindTexture(GL_TEXTURE_2D, texture/*4*/);
> 		glTexCoord2f(0.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 1.0f);
> 		glTexCoord2f(1.0f, 0.0f);	glVertex3f(-0.5f, -0.5f, 0.0f); 
> 		glTexCoord2f(1.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 0.0f);
> 		glTexCoord2f(0.0f, 1.0f);	glVertex3f(-0.5f, 0.5f, 1.0f);
> 	glEnd();
> 
> 	glTranslatef(0.0f, 0.0f, 0.5f);
> 	if (zoom >= -3)
> 		glRotatef(yrot-=0.01f, 0.0f, 1.0f, 0.0f);
> 
> 	glTranslatef(0.0f, 0.0f, (zoom * -1.0f - 0.5f));

Ok, here's why your zooms and translates don't work: they are being done
after the vertex submission. I think even in the regular GL this would
happen because the transformations only happen to vertices after the
glTranslatef(), glRotatef(), etc.

> 	if (zoom < -3) zoom++;
> }
> 
> /* Load a texture using pcx_load_texture and glKosTex2D */
> void loadtxr(const char *fn, GLuint *txr) {
> 	uint32 txaddr;
> 	int w, h;
> 	if (pcx_load_texture(fn, 1, 0, &txaddr, &w, &h) < 0) {
> 		printf("can't load %s\n", fn);
> 		return;
> 	}
> 
> 	glGenTextures(1, txr);
> 	glBindTexture(GL_TEXTURE_2D, *txr);
> 	glKosTex2D(GL_RGB565_TWID, (GLsizei) w, (GLsizei) h, txaddr);
> }
> 
> extern uint8 romdisk[];
> int main(int argc, char **argv) {
> 	cont_cond_t cond;
> 	uint8	c;
> 	int i;
> 
> 	/* Initialize KOS */
> 	kos_init_all(THD_ENABLE | IRQ_ENABLE | TA_ENABLE, romdisk);
> 
> 	printf("gltest beginning\n");
> 
> 	/* Get basic stuff initialized */
> 	glKosInit();
> 	glMatrixMode(GL_PROJECTION);
> 	glLoadIdentity();
> 	gluPerspective(30.0f, 640.0f / 480.0f, 0.1f, 100.0f);
> 	glMatrixMode(GL_MODELVIEW);
> 	glEnable(GL_TEXTURE_2D);
> 
> 	/* Load the textures */
> 	//loadtxr("/rd/title.pcx", &texture1);
> 	//loadtxr("/rd/created.pcx", &texture2);
> 	//loadtxr("/rd/kalist.pcx", &texture3);
> 	loadtxr("/rd/copyr.pcx", &texture);
> 
> 	c = maple_first_controller();
> 	while(1) {
> 		for (i = 0; i < 1000; i++){
> 		}
> 
> 		/* Check key status */
> 		if (cont_get_cond(c, &cond) < 0) {
> 			printf("Error reading controller\n");
> 			break;
> 		}
> 		if (!(cond.buttons & CONT_START))
> 			break;
> 		if (!(cond.buttons & CONT_DPAD_UP))
> 			break;
> 		if (!(cond.buttons & CONT_DPAD_DOWN))
> 			break;
> 		if (!(cond.buttons & CONT_DPAD_LEFT))
> 			break;
> 		if (!(cond.buttons & CONT_DPAD_RIGHT))
> 			break;
> 		if (!(cond.buttons & CONT_A))
> 			break;
> 
> 		/* Begin frame */
> 		glKosBeginFrame();
> 
> 		/* Handle the cube */
> 		glLoadIdentity();
> 		cube();
> 
> 		/* Finish the frame */
> 		glKosFinishFrame();
> 	}
> 
> 	return 0;
> }

The rest looks ok to me. On the textures looking wrong, did you mean
that they actually look incorrect, or that they are rotated wrong? I'm
not sure that I matched the texture system of GL so the rotation
problems might happen. If it's the other, then the first thing is to
make sure that it's a power of 2 in size. If it's not, then there might
be a bug (send me the PCX file and I'll take a look).

As a side point, does anyone know if it's valid in GL to do ortho mapped
graphics by simply doing a glLoadIdentity() on the PROJECTION matrix?
I'm doing that in the project I'm working on now to do 2D graphics
without having to use TA primitives, but I don't know if it's portable
or not.

Re: [KOS] Is this mailinglist also for beginners?

[Joachim J. <Joa...@lu...>]

Dan Potter wrote:

> Well, considering the outstandingly high traffic on the list so far
> (HEH) I think any questions at all would be alright.

Thank you for your answer!

I started to create a small gl-program, which shows a cube, zooming from the
distance to the front, starts to rotate to show me all his 4 textured faces.
The zooming works fine, untill to the point, where the cube should start to
rotate. At this point, my code to do the rotating seems to have no effect.
Additionally the texturing seems to be wrong... Nearly the same program works
fine (without texturing) under Mesa on FreeBSD.

Maybe you can have a look in my attached source and point me to my mistakes?

Thanks in advance!
Joachim.

Re: [KOS] Is this mailinglist also for beginners?

[Dan P. <ba...@al...>]

On Nov 28, Joachim Jaeckel wrote:

> I'm start interesting in developing for the dreamcast and in open-gl.
> Using KalistiOS 1.1.5 and the gl-part. The gl-examples runs perfectly,
> even the dc-tonic cd.
> 
> After that, I tried my first self-written program and run into a
> problem.
> Therefore, I would like to know, if I could ask my question here? To ask
> for a little bit support (maybe someone could have a look over my really
> short source-code and give me some tips) etc.

Well, considering the outstandingly high traffic on the list so far
(HEH) I think any questions at all would be alright. 

If you have general questions about getting a DC dev environment setup
(Cygwin, GCC on Linux, or what not) then it's probably better to ask on
the global dcdev list, but KOS specific questions can be directed here
and I'll try to help if no one else speaks up.

[KOS] Is this mailinglist also for beginners?

[Joachim J. <Joa...@lu...>]

Hello,

I'm start interesting in developing for the dreamcast and in open-gl.
Using KalistiOS 1.1.5 and the gl-part. The gl-examples runs perfectly,
even the dc-tonic cd.

After that, I tried my first self-written program and run into a
problem.
Therefore, I would like to know, if I could ask my question here? To ask

for a little bit support (maybe someone could have a look over my really

short source-code and give me some tips) etc.

Thanks in advance,
Joachim Jaeckel.

[KOS] Apologies

[Dan P. <ba...@al...>]

Sorry for that flurry of traffic there. I made a stupid mistake and
accidentally checked in our team project for operating systems into the
KOS CVS and had to hunt frantically for a way to delete it completely. I
found it, thank goodness, but if you grabbed any of that stuff please be
cool and delete it. We can get into some pretty obnoxious trouble for
having passed it around. Or at the very least, please keep it to
yourself until after December.

Back to your regularly scheduled program....

[KOS] Re: [dcdev] A question about STL/malloc on DC

[Dan P. <ba...@al...>]

cc'ing this to the KOS list also since it turned into a Dan core dump
;-)


On Nov 22, Chris Jefferson wrote:

> While I can see that there are cases where you want to
> keep track of these things (I've written a couple of
> programs with BIG hash tables, that just sucked up all
> the memory, but I could stop them growing if I ran
> out), personally I'd vote for a crash, as in most DC
> apps, I imagine that out-of-memory is a fatal error.

I'll probably do the out-of-memory handler bit. That's not a condition
that happens very often. What I'll probably do is make the crash the
default, and then make it possible to replace the handler with a
standard one that returns NULL, or let you put your own handler in
place. That'll be the most flexible.

Something else I want to get back in there is a platform-specific "BSOD"
function which takes a register frame and dies gracefully. It could also
potentially be swappable -- one version might use the console to print a
stack and register dump, along with a message; another version might put
up a nice pretty blue background and print an error code, and die (for
release). 

> On another (similar) note, I have a (tiny!) patch that
> does the same thing if you run out of VRAM. Actually,
> I've written a simple series of patches that let you
> split up the VRAM into smaller blocks and allocate
> and/or reset each of them seperatly, and it does
> optional bounds checking. However, it took me about 5
> mins to write so unless anyone desperatly wants it in
> KOS it's not worth diffing :)

I'd be interested in seeing it, it might give me some ideas.

I'm probably going to make a generalized dlmalloc for these sorts of
purposes which allows several things that are constants right now to
become variables stored in a configuration struct. This way malloc code
can be shared among different tasks like SPU and VRAM allocation, with
different default alignment requirements, etc. The main KOS malloc()
will still use the current one which is optimized for normal RAM access,
and the other would be available for any module that wanted a general
malloc for a seperate region. I can even see that being useful on other
platforms as time goes on, since most platforms have several seperate
memory areas that can be managed in-place dlmalloc style.

BTW, I'm building up a to-do list of this sort of stuff which I will
probably not be able to act on for a bit, but when the time comes
around, it will give me ideas for things to work on. Here are some
others in my queue:

- "Fast IRQs": this would be a special way to set an IRQ handler so that
you could process it without the OS saving any state information at all.
The SH-4, for example, is capable of operating an interrupt handler with
no state saving as long as you only use R0-R7. Obviously this would only
be useful in assembly code, but it might be helpful for things like very
high speed timers for doing copper effects. Some platforms like ARM
actually have a fast IRQ mode which (unless I've forgotten it already,
heh!) saves everything for you implicitly by switching out the whole
register set. Anyway, it can be a useful feature.

- New version of lwIP: just need to do it. Will probably try to make the
socket library that comes with it available as well.

- PowerVR volume modifiers and punchthrus: this needs some
experimentation and probably some more reverse engineering work, but I'd
like to have it working at some point. It's a nifty feature.

- "Port" some libdream docs: a lot of libdream's docs are still
applicable to KOS, they just have different function names, and
sometimes slightly different semantics. It would be a very good start to
a KOS documentation set. I always find that getting started is the hard
part, so that would certainly help.

- Official S3M player support: right now you're pretty much on your own
when handling S3Ms and such. I'd like to make an official addon lib that
does this for you, and sound effects. Likewise I'd love to integrate
Maiwe's XM player, even if it's not perfect. The S3M player isn't
perfect either, but it's more than adequate for the task.

- Hardware GD-Rom driver: all the info is available in NetBSD and
Linux-SH, just need to dig around there and compile it all to build a
new driver.

- Maple and SPU interrupts: this would allow me to get rid of polling on
maple stuff when threads are enabled, and to receive interrupts from an
SPU program so that you can synchronize events in the SH-4 to the SPU.
I'm pretty sure that both games and emulators could benefit from this
greatly (since you could then run the emulated SPU on the SPU itself...)

- Union VFS: just a matter of getting it written.

- Fixed up VMUFS: need to write a low-level file-level library, and then
build a new VFS on top of that. That way you could use it either way,
since it's more appropriate in many cases to do it the low-level way.

- Streaming library: now both Ogg Vorbis and libmp3 use the same
streaming code, but there are two versions of it which must be
maintained seperately. I'd like to factor out the streaming code into
its own piece (potentially in KOS' arch, since it might be useful for
other platforms, and would allow a platform-independent way to do MP3
and OGG playback). 

... there's more, but I suppose it's a bit far off. For example, once
there's a working and consistent lwIP installed, I'd like to build a
simple web browser that can be skinned and used in any KOS app, kind of
like Sega had their standard browser component. It might not even do
HTML, it might just pull from a special file on a given site so that you
can provide product info. Anyway, just a thought.

There are also a few people interested in doing various ports. If you
happen to be one of them, it'd be cool if you get on the KOS mailing
list and mention it there, you might find unexpected helpers =). I have
heard interest in a PC (X-Box) port, a PS1 port, and a PS2 port. I just
saw a GameCube a few minutes ago, and that has me salivating enough to
consider doing a port to that once there's some hacking info =). I'd
like to start making more of KOS portable too (like parts of KGL, MP3,
OGG, etc).

BTW, if you got this through the KOS list then make sure to respond to
the list and not me directly (unless you meant to).

Re: [KOS] SF list crappiness

[Dan P. <ba...@al...>]

On Nov 15, Warren Moore wrote:

> Looking at the listinfo and admin pages, the sf lists are based on
> mailman. Don't know how much they've mangled them (don't have any sf
> lists, only plain mailman ones), but on the General Options (first)
> admin page there's:-
> 
> Where are replies to list messages directed? Poster is strongly
> recommended for most mailing lists.
> ( ) Poster ( ) This List ( ) Explicit Address
> 
> Changing this sorts out mine :o)

Yeah, it looks like they took that option out.

Well, in that case I may look into moving the KOS mailing list
elsewhere.. that's a sufficiently irritating problem on the lists I've
been on in the past that I'd be willing to do that if I find a good
place.

Re: [KOS] TA Multires Patch

[Warren M. <wa...@wa...>]

Looking at the listinfo and admin pages, the sf lists are based on
mailman. Don't know how much they've mangled them (don't have any sf
lists, only plain mailman ones), but on the General Options (first)
admin page there's:-

Where are replies to list messages directed? Poster is strongly
recommended for most mailing lists.
( ) Poster ( ) This List ( ) Explicit Address

Changing this sorts out mine :o)

Warren

Bill Williamson wrote:
> 
> I'm on two other sourceforge lists and they all have the same problem.  I
> think you're fucked if you're using sourceforge's list.
> 
> If you do find a way to change it, let us know, I'd love to share the info
> with the other lists I'm on.
> 
> --Bill
> ----- Original Message -----
> From: "Dan Potter" <ba...@al...>
> To: <cad...@li...>
> Sent: Thursday, November 15, 2001 11:40 AM
> Subject: Re: [KOS] TA Multires Patch
> 
> > Oops, that was supposed to go to DCG I think...
> >
> > This "reply to sender" crap on this list is really starting to annoy me,
> > I'm going to see if I can get it to set the Reply-To to the mailing list
> > (yes, I have heard the holy rants about why this is bad, but I think the
> > results of leaving it off are annoying enough to warrant it).
> >
> >
> > _______________________________________________
> > Cadcdev-kallistios mailing list
> > Cad...@li...
> > https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
> >
> >
> 
> _______________________________________________
> Cadcdev-kallistios mailing list
> Cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

-- 
Warren Moore - http://www.waz.org.uk

Re: [KOS] TA Multires Patch

[Bill W. <ba...@ha...>]

I'm on two other sourceforge lists and they all have the same problem.  I
think you're fucked if you're using sourceforge's list.

If you do find a way to change it, let us know, I'd love to share the info
with the other lists I'm on.


--Bill
----- Original Message -----
From: "Dan Potter" <ba...@al...>
To: <cad...@li...>
Sent: Thursday, November 15, 2001 11:40 AM
Subject: Re: [KOS] TA Multires Patch


> Oops, that was supposed to go to DCG I think...
>
> This "reply to sender" crap on this list is really starting to annoy me,
> I'm going to see if I can get it to set the Reply-To to the mailing list
> (yes, I have heard the holy rants about why this is bad, but I think the
> results of leaving it off are annoying enough to warrant it).
>
>
> _______________________________________________
> Cadcdev-kallistios mailing list
> Cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>
>

Re: [KOS] TA Multires Patch

[Dan P. <ba...@al...>]

Oops, that was supposed to go to DCG I think...

This "reply to sender" crap on this list is really starting to annoy me,
I'm going to see if I can get it to set the Reply-To to the mailing list
(yes, I have heard the holy rants about why this is bad, but I think the
results of leaving it off are annoying enough to warrant it).

Re: [KOS] TA Multires Patch

[Dan P. <ba...@al...>]

On Nov 15, DCGrendel wrote:

> Theres still one bug I can't find the cause of,
> If you attempt to render with the framebuffer set to 640x512, 768x576,
> or 800x608 you get a variety of symptoms:
> 
> 800x608: incomplete-list errors.
> 768x576: only 32x64 region rendered, rest of display is black.
> 640x512: black screen.
> 
> It seems that its a vertical timing issue or something similar,
> 800x480 and 768x480 work perfectly as far as I can tell.
> I know that the dreamcast should (does?) support 640x512 at the minimum,
> and higher would just be nice to have.  Any ideas?

Well, if you want to contribute some extra modes like the above, then I
would more likely be able to debug the problems. Other than that, I have
no idea..

[KOS] KOS Statistics

[Dan P. <ba...@al...>]

We were discussing "big projects" at work, and someone started the
inevitable "my code is bigger than yours" war, so I did some line
counts on KOS. Some scary stuff...

283  C files comprising 79088 lines of source     
191  H files comprising 19739 lines of source
748  Misc (counting directories unfortunately)

[KOS] New dlmalloc

[Dan P. <ba...@al...>]

I just grabbed the latest sources from Doug Lea's FTP for his dlmalloc
and integrated them into KOS CVS. It seems to work and be relatively
stable, but of course please let me know if anyone sees problems.

Of special note, this newer dlmalloc has nice support for thread
locking. I found some pretty serious bugs in the old dlmalloc (or
rather, serious bugs in my thread-ization of it ^_^;;) which are fixed
now.

Also, I have taken a look at this and discovered that it has two cool
features. The first is that the default alignment is variable, so it
should be possible to build a texture or spu ram allocator using this
system (which I plan to do). The second thing is that it uses relatively
few global variables, so it ought to be possible to make a generic
allocator which can use different pools of memory with the same code.
Most of the management data is stored in the memory pool itself. I'll
probably make that a special case of the current dlmalloc and make a
generic allocator system for any other memory pools in whatever console
/ PC / whatever. I'd make the system memory allocator part of the same
system, but I don't want to slow it down any further than absolutely
neccessary. 

Re: [KOS] TA Multires Patch

[Dan P. <ba...@al...>]

On Nov 14, DCGrendel wrote:

> Ok, as it stands, the current cvs and 1.1.5 have one thing (as far as I 
> can tell) preventing using other video modes (custom modes such as 
> 768x480 or 768x576) from being used for 3D rendering.  As long as I've 
> not overlooked anything, the following patch will allow you to render to 
>  sizes other than 640x480.

Nice catch there.. It looks correct to me, I can't believe I missed it
;-)

I applied that patch to the CVS tree and opened the 1.1.6 CHANGELOG
today.

[KOS] TA Multires Patch

[DCGrendel <dcg...@co...>]

Ok, as it stands, the current cvs and 1.1.5 have one thing (as far as I 
can tell) preventing using other video modes (custom modes such as 
768x480 or 768x576) from being used for 3D rendering.  As long as I've 
not overlooked anything, the following patch will allow you to render to 
  sizes other than 640x480.



XXXXXX  SNIP    kos-1.1.x-ta_multires.patch     SNIP  XXXXXX
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/


*** ta.c        Sun Nov  4 05:22:45 2001
--- ta.c        Wed Nov 14 09:57:14 2001
***************
*** 181,188 ****
         ta_state.tw = w/32; ta_state.th = h/32;
         ta_state.tsize_const = ((ta_state.th-1)<<16) | 
((ta_state.tw-1)<<0);
         ta_state.zclip = 0.0001f;
!       ta_state.pclip_left = 0; ta_state.pclip_right = 640-1;
!       ta_state.pclip_top = 0; ta_state.pclip_bottom = 480-1;
         ta_state.pclip_x = (ta_state.pclip_right << 16) | 
(ta_state.pclip_left);
         ta_state.pclip_y = (ta_state.pclip_bottom << 16) | 
(ta_state.pclip_top);

--- 181,188 ----
         ta_state.tw = w/32; ta_state.th = h/32;
         ta_state.tsize_const = ((ta_state.th-1)<<16) | 
((ta_state.tw-1)<<0);
         ta_state.zclip = 0.0001f;
!       ta_state.pclip_left = 0; ta_state.pclip_right = w-1;
!       ta_state.pclip_top = 0; ta_state.pclip_bottom = h-1;
         ta_state.pclip_x = (ta_state.pclip_right << 16) | 
(ta_state.pclip_left);
         ta_state.pclip_y = (ta_state.pclip_bottom << 16) | 
(ta_state.pclip_top);


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
XXXXXX  SNIP    kos-1.1.x-ta_multires.patch     SNIP  XXXXXX

[KOS] KOS 1.1.5 released

[Dan P. <ba...@al...>]

KOS 1.1.5 has been released. Not a whole lot else to say at the moment.
Check the SF link for downloads. This release includes a lot of goodies
including some sound fixes, thread sync fixes, floating point printf()
support, KGL translucency, up-ported KOS-MMU MMU module, polygon culling
control in KGL, and OggVorbis (plus two examples). A big thanks to
everyone who submitted code and fixes in this release!  

http://sourceforge.net/project/showfiles.php?group_id=23791&release_id=61041

Files should show up shortly.

[KOS] Two patches today

[Dan P. <ba...@al...>]

FYI: I checked in two interesting patches today. One from Andrew enables
polygon culling control in KGL, which is helpful for two-sided polygons
and translucent polygon usage. The other is a port of the MMU code from
KOS-MMU. I haven't tested it but it does compile and it worked in
KOS-MMU. I'll probably cook up a simple example a bit later.

[KOS] Testing!

[Dan P. <ba...@al...>]

I don't think anyone has actually posted much to this list, so I'm just
testing to see if it's all working. I haven't even been subscribed until
now. ^_^;;

Well, to make this message not a total loss, I just checked in a nice TA
fix that will really turn off vertical smoothing for VGA box users. I
thought it was doing this before, but there was a really stupid bug in
the setup code that made it revert the change. The visual quality is
probably an order of magnitude nicer looking. This fix will go into
1.1.5 and it's already in CVS.

Also posted this news on the dcdev.allusion.net site today, in case
anyone is interested:

-------------------------------------
Just a couple of small updates here.... 

 1. I tried to change the mailing list to cadcdev-kos, but it
    tells me the name must be at least 4 characters long. This
    is probably why I made it "kallistios" instead. Cope, and
    subscribe to that one if you want =).
 2. I created a new list, cadcdev-kos-commits, which will be
    the target of future CVS commits. It doesn't include the
    latest round and it'll take a few hours for them to finish
    setting it up, but it should help out for people following
    KOS development.
 3. A big round of changes (including a lot of submitted
    patches) just got checked in today. Some more KGL
    translucency stuff, semaphore/condvar fixes, TA goodies,
    initial SPU DMA code, etc.

We're getting pretty close to a 1.1.5 release now. I like to
wait until the changelog gets to be about a page and then post
a new release. =)
-------------------------------------

I tried the CVS commit list a minute ago and it seems to be having some
problems. I'll try to get that worked out in the near future. Anyone
who's interested can go ahead and subscribe to it, though.

ack, 4:30AM, time for me to go to SLEEP! =)