[C++] Conflicting Issues pt 1

[Clyde]

strange thing happend to me Today, the proggie I was working on worked in the sense of it rendering and updating etc. I added a new function which only dealt with a different way of making a colour palette, and then everything went tits up. I have even removed that function. And im wondering if ive found a gremlin again.
 
im using the usual suspects from my previous adventures w/2008, tinyptc, libmmx, MSVCRTS. Im getting these in the build dialog ( btw using MSVC++ 2010 express )
 

 
1>------ Build started: Project: Wicked Plasma, Configuration: Release Win32 ------
1> wicked plasma 1-1.cpp
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1> Generating code
1> Finished generating code
1>MSVCRTS.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (40000040) merged into '.data' (C0000040) with different attributes
1>MSVCRTS.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (40000040) merged into '.data' (C0000040) with different attributes
1> Wicked Plasma.vcxproj -> C:Documents and SettingsClydemy documentsvisual studio 2010ProjectsWicked PlasmaReleaseWicked Plasma.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 
I wondered if anyone had any ideas,
Cheers and all the very best,
Clyde.[/]

[hellfire]

Just warnings
Does it still run?

[Jim]

If you're going to statically link against MSVCRTS.lib (you have it in your additional dependencies) then you need to set the Ignore Default Libraries in the Linker options as the error message suggests.  Otherwise you're linking against 2 different C runtime libraries from 2 different versions of visual studio!

Jim

[Clyde]

@Hellfire: It was working lovely jubbly and its now strange it doesn't, this has got me thinking weather there's something up with the gfx_buffer * as I have updated my gfx card last night.

@Jim: Did that dude, i now get a build error and: 1>wicked plasma 1-1.obj : error LNK2001: unresolved external symbol @__security_check_cookie@4

I've also noticed a new feature of a short cut in the Solution Explorer "External Dependencies"

[Clyde]

well, im buggered if I know CPPs game. i've commented out some of the image class ptrs, and i get it to run and then again it doesnt. ive even tried with and without static gfx_buffer *buffer1, *buffer2, *buffer3; but that still doesnt explain why it was running for most of the day.

last straw is to compile and run and see if it's happening in express 2008.

likewize im just guessing. I don't think God wants me to learn this stuff

[Jim]

OK, the real problem is that you are trying to use the ptc lib, and a version of C++ that it's not compatible with (it's not very friendly with Visual C++ at all, as you've found out - you've spent all the time frigging around with ptc and compiler options and no time at all working out how to code the language, or anything at all to do with coding Windows), and trying to link against an ancient static C runtime library. The compiler is generating code that depends upon a specific C runtime library.  It's possible to work round it, by endlessly tinkering with the options (I think this one is in the compiler options to do with array bounds checking).  We would be better off kicking ptc in the head, writing a simple window code (I've posted several frameworks here in the past) and building on that.  We can move on to tiny apps with no C runtime and crinkler after you actually understand what's going on.  There's nothing wrong with the compiler, just what you are trying to achieve with it is perverse. 

Jim

[Jim]

Been thinking about this some more...if I came up with a bit of cpp code and a project file set up to look like ptc, written with maybe d3d9 so you could do pixel stuff, that might be more useful than a lib.  I'll see what I can come up with this weekend.

Jim

[Clyde]

Cheers Jim that would be awesome!
 
Thanks man

[Jim]

Here it is http://www.dbfinteractive.com/forum/index.php/topic,4747.0.html

Jim

[Clyde]

their becoming a regular feature and in release mode.
might be a setting, maybe not allocating enough memory. finally and hopefully my gfx card isnt bUgGerReD.

[Jim]

You either haven't made sure the memory you've allocated for the sprites has been cleared to 0xff000000 or you're not plotting black into the background or the font didn't load the same way in release mode, or something else.  But it's impossible to tell without the exact code that you have that does this.

I've mentioned before that VC runtime in debug mode does things  to clear memory to magic values so you see mistakes sooner (it's allowed to do this and it really helps).  Looks like your code is probably dependent on these magic numbers in some way so you are seeing the problems in release mode instead.  It's usually the other way round, but hey!

Have you tried using the debugger?  You can still use it a bit in Release mode.  F9 sets a breakpoint, then when you run it the code will stop at that line and you can inspect all the variables and memory.

Jim

[Clyde]

Not used the debug thing much.
It happens to alot of routines, so I didnt put up anything specific.

I've just tried someting and added this.

Code: [Select]

for ( int a=0; a<(wwidth*height); a++ )
{
        buffer->pixels[a]=0xff000000;
}

and the greenie meanies upped and left.
will experiment and see if that's cured it for other projects.
 
{edit} a few routines that weren't green friendly are ok.
I now have graphics displayed offset as they move. didnt have that in my tinyptc adventures.

[Jim]

More bugs to fix then
Jim

[Clyde]

yep!
even though I haven't done anything differently between tinyptc and dxd9ptc.
if you look at the image attachment up a few posts, you'll see the weirdness that's happening on my screen. Also, if I have that drawing more or less near the center of the screen, there's a faint diagonal line playing with the pixels.

[Jim]

How come the green stuff doesn't appear in the "conflicting issues" code (release or debug)?  If it was something to do with the framework (which I'm positive it's not) then it would be everywhere.
Jim
PS. I've fixed the diagonal line, grab the code again from the other thread.