Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darklord92]

well the main error is that the second sprite refuses to draw even if you set a specific location on screen when creating it.

as for the moving faster thats probably due to the crappy code that was attempting to keep sprite 2 above sprite 1 ( think how mario is 2 sprites tall)

Yes i have a debugger on fce ultra to step the code

[Virex]

You don't need to do anything special to keep sprite 2 above sprite 1, you're already setting the position of sprite 2 explicitly in the beginning of the loop. Besides, you're also using the same sprite for 1 and 2, but that's probably for testing purposes?


You could trying to step through the code and keep track of sprite 2's position, see if it's being set properly.

[alway]

<shamelessSelfPromotion>
More erosion simulation videos!
http://www.youtube.com/watch?v=ZCshxaa_sYs

And with the graphics update I added last night:
http://www.youtube.com/watch?v=V5t-aKt9ZkQ
</shamelessSelfPromotion>
So, the difference between the hideously terrible looking water and the awesome shiny water?
Very simple changes to the shader.
The first change was making the water's color more closely resemble that of the sky/clear color.
The second change was adding a color gradient to the water based on depth; an easy enough change, as it just takes water depth into account, blending the colors accordingly with a simple linear equation.
The final change was specular reflection, which is what makes it shiny.
And that's the only difference between pretty shiny water and blue flow-y stuff.

[Siquo]

Wow, that is a big difference. Looks pretty awesome, what are you going to do with it?

[Valid_Dark]

I really need to learn to start leaving more notes in my code,
started working on something I hadn't touched in about 2 months, and it's a headache figuring out what the hell I was thinking.

P.S. it's shitty programming without a mouse, and I may be looking for a new artist here soon, as I haven't been in contact with my current artist for about a month or two and he's not responding to emails / msg's, (I would do the art but I'm mouse-less atm and it's pixel stuff)

also, Alway, that's looking rather sexy, nice improvement.

[MorleyDev]

Working on creating my own Unit Testing and Mocking framework (none of the existing C++ ones match what I want).

So far what I have seems alright. It's based on a BDD-like "Given-When-Then-Finally" format where you define a test as

Given A
- When B
-- Then C
-- Then D
-- Then E
- When F
-- Then G
- Finally H
Given I
-- Then J

Which would call the logic for:
Given A When B Then C Finally H
Given A When B Then D Finally H
Given A When B Then E Finally H
Given A When F Then G Finally H
Given I Then J

The idea is to allow for a more natural "Arrange-Act-Assert" style to tests, whilst allowing to add a Tear Down step (finally). The idea is to make it so that Tests can be nicely formatted but it's loose enough to be very flexible, whilst actual BDD tends to be too strict about things for my likings. There may need to be a step tearing down each When, like how Finally tears down the Givens, but I'm a bit conflicted on that one. Maybe if a scenario where I need that appears...

The only thing required here is the Then, if you skip the Given or When or Finally it's treated as if those steps had logic that did nothing. The test defines the requirements for the class more in programmer terms than in managerial terms (which BDD tends to do if you ask me).

Combine it with a recreation of Nunits "natural language" style Assert.That(X, Is.SomePredicate) (here rendered as AssertThat(X, ut11::Is::SomePredicate)) and I'm kinda satisfied with what I managed to squeeze out of C++11, at least for the moment. It's a lot less Macro heavy than most testing frameworks, which is pleasing. It should work fine in GCC 4.7+ (since that's what I developed and tested it with), and may work with the November CDT for 2012 since that brought the main missing feature, Variadic Templates, into play. But VS2012 is not something I've tried.

The mocking "framework" in it needs love and me to figure out a neatish way of handling it. What's there...works-ish? For now at least. Mocking in C++ is bloody tricky stuff because of the lack of reflection. Whilst there are some libraries out there, such as Google Mock, they are all too "Expectations Up Front" for my liking (Asserting the right parameters were passed comes in the Assert step, not during the Arrange or Act, which would be where Google Mock puts it).

[Skyrunner]

On Microsoft Visual Studio 2010 Ultimate, sometimes compiling and building takes so very long, much longer than it should. For example, changing a single line of code in a cpp file takes a minute or longer to build. Does anyone have any experience with this kind of problem? A quick google search didn't turn up anything helpful — most question-askers were using some sort of external extension or utility to aid their building, that interfered with msvc. Mine has no extensions at all.

[olemars]

If you put a lot of #includes in your header files, and especially if you haven't used header guards, the compiler will spend a lot of time parsing instead of compiling.

[Skyrunner]

Are header guards #ifdef #endif, instead of #pragma once?
Also: should #includes be in the cpp files instead? o_O I thought they were supposed to be all put in the cpp files...

[olemars]

Are header guards #ifdef #endif, instead of #pragma once?

Either works.

Also: should #includes be in the cpp files instead? o_O I thought they were supposed to be all put in the cpp files...

Best practice is to put #includes in the .cpp, to minimise file reads. If you put lots of #includes in a .h, then every file that includes that .h will also have to process the contained #includes as well. Header guards help, but there's still overhead.

If you have pointer member variables in a class, use forward declaration in the .h and include in the .cpp. Anything that's only used locally in the cpp should also only be included in the cpp.

[Mego]

Are header guards #ifdef #endif, instead of #pragma once?

Either works.

Sort of. Most standards-conforming compilers (once again, MSVS is not included) are phasing out #pragma once. That is, if they even supported it to begin with, since #pragma is a compiler-specific directive. So while #pragma once may work now on the compiler you're using, it may not work on other compilers, and will not work at some point in the future. The #ifndef/#define/#endif idiom is universally supported, and is not going away anytime soon, so it's a much better practice.

[Siquo]

#pragma once is supported by most compilers, is faster on some of them, and will not be deprecated in the foreseeable future.
It's a lot less typing and less error-prone, so using it is less practice and makes life easier

So yeah, you can use either.

[Immortal]

I was wondering if anyone else is into AI?

[GalenEvil]

* GalenEvil raises hand in regards to Immortal's question

I am very much into AI. It's about half of my current programming work The other half is mostly PCG stuff and random other things that I am contracted to do hehe

[Mego]

A new semester has begun. Two new compsci classes have appeared. A new (old) challenger steps forward.

Visual Basic (lolno)

C! Not C++, but C! I have a compsci course that uses C as its programming language. And, the more I use it, the more I realize that I take C++ features for granted, and when I don't have them anymore, I'm much slower at coding.