7 replies to this topic

[15dice]

This one should be easy. I hope I'm being an idiot. Here goes.

I'm passing an number by value (200), and it's showing up as 0 inside the function. I'm using Turbo C. No problems until now; written a partial software renderer.

If someone could just trace through this, I would be very appreciative... I cannot debug this.

InitBuffer( 320, 200 );


void InitBuffer( uint32 width, uint32 height )

{

	uint32 i;


	sprintf( buf, "width: %u, height: %u\n", width, height );

	Log( buf );

  ...

}


Log shows: 


width: 320, height: 0

Proj is HERE, with whole environment, just run c.bat to compile. main.c has the call to InitBuffer(), and 2DCanvas.c defines InitBuffer(). Basically I am fine when I animate a shape in the center of the screen, but when I bring it off the lower half of the screen, I get this problem. I do not believe there are any memory leaks (it's too early in main.c for that to happen). Also, when a pixel is to be drawn is out of bounds (SetPixel()), I don't draw it.

What SHOULD happen is, the shape should animate, even though half off-screen.

Regardless of all that... passing by value is pretty fundamental!! :)

[Reedbeta]

Holy crap. You're writing a DOS mode 13h software renderer, using Turbo C? Are you living 10 years in the past? I can't even run this in Windows XP, let alone debug it. Maybe you should try writing a software renderer that uses DirectDraw in a window? You could still do most of the same things you are now doing.

[15dice]

Reedbeta said:

Holy crap. You're writing a DOS mode 13h software renderer, using Turbo C? Are you living 10 years in the past? :blink: I can't even run this in Windows XP, let alone debug it. Maybe you should try writing a software renderer that uses DirectDraw in a window? You could still do most of the same things you are now doing.

I know it's really a throwback, I wanted to use mode13h. Anyhow, haven't had problems up to this point. Debugging is a bit slower but still simple.

And yes mode13h is supported in WinXP, and it runs fine.

[Sol_HSA]

If you want to run the mode 13h in a window, you can try to use my SolVBE - http://sourceforge.net/projects/solvbe

It's a universal VESA VBE 1.2 'driver' for windows, but it also supports 13h mode.

Now, if you want to come back to the modern times but still do things on a pixel level, I've written this tutorial series - http://iki.fi/sol/gp/ - for that very reason.

[Nils Pipenbrinck]

InitBuffer( 320, 200 );


void InitBuffer( uint32 width, uint32 height )

{

	uint32 i;


	sprintf( buf, "width: %u, height: %u\n", width, height );

	Log( buf );

  ...

}


Log shows: 


width: 320, height: 0

I think the standard int on turbo c is just 16 bit wide.

You're passing a int32 though. I'd expect the compiler to push the width and height with 2 int16 each (lowword first, then highword). sprintf will handle these as two arguments.

If you'll add two additional %u's to the formatline, You'll get an output of 320 0 200 0.

Just cast the arguments (width and height) to int before passing them to sprintf.. e.g:

InitBuffer( 320, 200 );


void InitBuffer( uint32 width, uint32 height )

{

	uint32 i;


	sprintf( buf, "width: %u, height: %u\n", (int)width, (int)height );

	Log( buf );

  ...

}

Nils

[Rofar]

In the code snippet posted, I don't see the variable "buf" declared anywhere.

[15dice]

I actually typedef'd int as int32 myself even though it may well be 16 bits.

Rofar said:

In the code snippet posted, I don't see the variable "buf" declared anywhere.

It's global for the moment.

I think I will switch compilers, to make debugging easier. Plus, I've seen other strange problems with turbo C. In one case, it wouldn't let me declare a function with "Matrix4f*" as its "first parameter", even though I did it elsewhere. Thx Borland. ;)

[Reedbeta]

Yeah, it would be a good idea to use a more modern compiler - especially since MSVC 8.0 Express is freely available these days.