Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ameise

Member Since 13 Jan 2007
Offline Last Active Dec 03 2014 08:32 PM

#5196172 Default font texts from windows

Posted by Ameise on 03 December 2014 - 08:12 PM

I'm a fan of the Liberation Fonts.




#5129144 fractal result by accident

Posted by Ameise on 05 February 2014 - 03:24 PM

 

 

Clearly an aliasing effect and nothing fractal about it.

 

If you say so ;\ (yawn)

 

 

Why do you bother asking if you're just going to reject the answers you get if they don't match your predetermined presumptions? I concur that it just looks like a Moiré pattern.




#5128463 Why would devs be opposed to the PS4`s x86 architecture?

Posted by Ameise on 03 February 2014 - 11:12 AM


X360's x86 architecture could perform 77 GFLOPS, the PS3 could perform 230 GFLOPS.


Just to nitpick, but the XBox 360 didn't have an x86 processor - it was a PowerPC just like the PS3 but with a different internal architecture. Perhaps you meant that the design of the Xenon CPU is more similar to a PowerPC version of common x86 chips than it is to the distributed design of the Core CPU?




#5080275 Better FPS with high-poly terrain

Posted by Ameise on 24 July 2013 - 05:51 PM

In other words, you implemented a O(log n) solution a la spatial subdivision?




#5079031 Generating Terrain on the GPU vs on the CPU

Posted by Ameise on 19 July 2013 - 04:14 PM

Graphical applications usually are bottlenecked by pixel shader, while vertex shader and cpu are being idle most of the time. People usually move computations from cpu to vertex shader to save cpu/memory resources for other cpu specific tasks like AI, physics.

In your case, you have moved some calculation from cpu which was idle most of the time to vertex shader which was also idle most of the time. The performance of your application was determined by pixel shader which was not changed and overall performance of your application was not changed, too. But you should be able to see difference in loads on cpu and vertex shader using some performance profiling tool like Nvidia PerfHud.

 

Most modern GPUs have unified shader models, so there are no dedicated vertex or fragment units. They are shared.




#5079021 Uniform Location = -1 even though Uniform is Active

Posted by Ameise on 19 July 2013 - 03:21 PM

I'd point out again that it is likely this line:

 

float shadowFactor      = (curSunSpaceDepth < sunSpaceDepth) ? 1.0f : 1.0f;

Since both sides of the ternary are 1.0f, the compiler is likely compiling away the conditional, and since those are the only places that those variables are referenced, it is recursively compiling out those two uniforms. Most likely, if he changes one of the 1.0f's to 0.0f, he will stop getting -1.

Not to say he shouldn't correct his code otherwise, but that's probably not why this is happening.




#5079008 Uniform Location = -1 even though Uniform is Active

Posted by Ameise on 19 July 2013 - 02:35 PM

Outside of that, I'd suggest the issue has to do with this line:

 

float shadowFactor      = (curSunSpaceDepth < sunSpaceDepth) ? 1.0f : 1.0f;



#5050065 This error has me perplexed.

Posted by Ameise on 04 April 2013 - 01:49 PM

Also, see if there's some sort of memory debugger that you can use. One of the first programs I turn to for things like this is Valgrind, which would give you a heads-up once various memory errors occur.

 

"VS2012 express edition"

 

Valgrind does not run on Windows.




#4958562 Memory Allocate new

Posted by Ameise on 12 July 2012 - 03:30 PM

Why were you downvoted??? you were spot on in everything you mentioned.

oh and yeah i completely forgot about 2[var] syntax. I never use it since its confusing.

What do you mean overloading new? I'm not sure i've come accross that use of new



Also monkeyboi other things about memory management:

  • When using new, as stated before, it goes to the heap. If you allocate too many items, you will run out of memory unless you deallocate them. When you continually allocate memory but never free it, this is called a Memory Leak
  • To deallocate, you use the delete key word.
    say I put SomeClass* x = new SomeClass(); to deallocate it just use delete x; (keep in mind this calls the destructor for SomeClass and frees the memory that x was pointing to, allowing later allocations to use that memory)
    but if you allocate an array you have to do something else; in the case of char* ca = new char[3]; you will have to use delete [] ca;


Overloading new... I don't recommend what I'm doing here (since it's stupid) but it's a quick example:
[source lang="cpp"]static char sBuffer[512];void * operator new (size_t sz){ return (void *)sBuffer;}[/source]
That won't return the pointer from the heap, but rather will return sBuffer.

In regards to placement new:
[source lang="cpp"]char buffer[512];new (buffer) Object;[/source]

That also will not use the heap, but will construct the object within buffer.

For placement new, do not ever call delete. Call the destructor manually. It will crash/cause a black hole as it is not a valid pointer to data on the heap.

[source lang="cpp"]char buffer[512];new (buffer) Object;((Object *)buffer)->~Object();[/source]

Although technically beyond the scope of mid-level C++, he should also have familiarity with the C allocators (malloc, calloc, realloc, ...) and deallocator (free).

They function relatively the same as new (with a few caveats) except that they do not call constructors/destructors. The pointers may also not be interchanged between malloc and delete, for instance.

alloca, if it's present, will allocate the memory on the stack (by decrementing the stack pointer, generally). I don't usually recommend it as it's not safe - a failure for alloca to allocate results in a stack overflow.


#4958558 Memory Allocate new

Posted by Ameise on 12 July 2012 - 03:08 PM

I'm wondering why I was downvoted without any comments explaining what was wrong with what I wrote Posted Image

I first came accross std::string before i learned about char arrays. This was way back in HS in intro programming. But i feel you are right he needs to understand pointers, allocation, and buffer limitations.

Key thinks that monkeyboi needs to know about C-style strings (aka char arrays):

  • There must be a zerobyte/null byte inside that determines the end of the string. '\0' is the ASCII symbol for it, but 0 is also fine. When using strlen it counts the number of characters up until it find this zerobyte. This is why he had odd answers since the char[] was undefined upon initialization. When you put char[4] tc = "123"; you are really putting '1', '2', '3', '\0', filling it up; this extra step of putting the zerobyte at the end is just a feature of c++ (and C i believe)
  • Even if it has a zerobyte, never access/overwrite an element outside of its bounds (dont ever use tc[-2] or tc[n], or any larger number, only 0->n-1 ).
  • Keep in mind the compiler will not warn you if you go out-of-bounds, since it doesn't really know the size of the array, only in the case of declaration and putting something too big will it ever tell you something (char [4] tc = "1234", was too big since '\0' is a fifth additional byte added on)
  • When you use new, it goes to the heap in the CPU memory, which is a special place for dynamically allocated memory, or run-time(?) allocation.
  • Always remember that char[] is still a pointer, as are all arrays. tc itself is the pointer to the first element of the array, as in the case above *tc would be '1'; *(tc+1) is '2', *(tc+2) is '3' and *(tc+3) is '\0'. When you use tc[0] or tc[2], it is just a "shorter" way of doing *(tc+2).
  • char* and char[] are in many ways equivalent, just char[] is explicity announcing its array property, while char* could just be a pointer to a single char or possibly pointing to the beginning of a char array


Regarding 4, only if he uses the standard non-placement new operator. If it is overloaded, everything's up in the air. Placement new just uses whatever memory you're pointing to.

Regarding 5, 2[tc] is also '3' Posted Image I absolutely hate that syntax, though.


#4958545 Memory Allocate new

Posted by Ameise on 12 July 2012 - 02:32 PM

any time you use the "new" or malloc (C-style) allocation methods, it goes onto the heap, contrast to putting it on the stack (any local variables for example, like int f =3)

So indeed your array IS on the heap, since you used new. What I think Ameise was getting at is that since it is on the heap there is less chance of encountering important data, such as things like returning addresses (the place to go back to after a function call for example) which are stored on the stack (if you overwrite a return address it may very well cause a page fault and crash the program)

Edit: the point is that you do not want to go out of bounds of any array or invalid memory. Even if you overwrite harmless data, you risk the opportunity to contaminate either your own program executing, the operating system, or other programs. This is why std::string is much better alternative to C-style strings (char[]) because you don't directly deal with pointers. Also it has its own size() function, as well a multitude of manipulating functions. All in all std::string is more flexible, useful, and easier.


My other point still stands in that regards, though, in that he shouldn't be using std::string until he understands CStrings. In regards to the standard lib, I don't usually recommend using things until you have an understanding of how they work.


#4958486 Memory Allocate new

Posted by Ameise on 12 July 2012 - 11:41 AM

If you need space for strings, consider using std::string instead.


Knowing and using std::* classes is not a replacement for actually understanding how the language works, and in particular how memory allocation works, particularly with a relatively low-level language such as C++. When he has a good understanding of the fundamentals, a basic understanding of the std::* classes and knowledge that he should use them should come along with it.

To the OP:

The reason that strlen is not returning the size of your array is simply due to the fact that that is not the purpose of strlen.

strlen returns the length of a C String, that is, a null-terminated character array.

You are allocationg 4 bytes of memory. However, that memory is coming out of the heap, and it is likely that there is "valid" memory after it (valid in that it won't crash, but undefined as per C++).

Since it is not initialized, it just has random junk. You are seeing strlen return 16. This is why:

| YOUR ARRAY |
[rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][rnd][0]

rnd is any random non-zero value.

strlen has no knowledge of your array or its size, and only has knowledge of the pointer and that it must seek the null terminator. The fact that you have consistently gotten 16 is coincidental.

It could very well return this:

| YOUR ARRAY |
[rnd][rnd][0][rnd]

In which case, strlen would return 3.

The reason it could CRASH is that it could have allocated your memory at the edge of a page allocation, for instance. When you go outside the buffer, you are now reading unmapped memory, which is a page fault. There are other reasons too, simply put - don't read outside of memory you are aware of.


#4946167 Why is C++ the industry standard?

Posted by Ameise on 04 June 2012 - 11:35 AM


You can tell my friend who works on database servers where the client interface is written in Java that.

Oh yes, loading the database into memory and blaming Java for being slow...


I never said it was slow; I said it used up a large amount of memory. When your server(s) are handling tens of thousands of clients, the overhead of Java starts to become rather large, to the point that prototype C++ implementations use a substantial amount less. Java will use more memory no matter what, due to the need to store metadata for practically everything.


...Or any Android mobile developer.

FYI: You don't run Java on Android.


No, you run Dalvik bytecode (as I've said many times in the mobile forum). However, Dalvik is bound by the same constraints as the JVM in that to perform the same tasks (handling Java behavior, JIT) it still requires a substantial amount of overhead (in the form of metadata and a background running JIT).

Alright, folks.

If we can't have a civil discussion without resorting to "yuh huh!" and "nuh uh!" all over the place, we're going to talk about something else.


It was civil at one point. I'm trying to give experiences from my professional career; if he wants actual data, he needs only ask for it, instead of insisting that I'm wrong without any evidence of his own to the contrary. Also, his rather openly hostile attitude isn't helping.


#4945437 stl::list crashing within a for loop

Posted by Ameise on 01 June 2012 - 04:05 PM

Change

m_vNumbers.erase( it );

to

it = m_vNumbers.erase( it );

You're invalidating the iterator by erasing it from the list. list<>::erase returns an iterator for this very purpose.

You will also want to change the iterator iteration logic as such:

	    while (it != it_end)
	    {
		  if (*it == obj)
		  {
				 it = m_vNumbers.erase( it );
		  }
		  else
				 it++;
	    }



#4945379 Why is C++ the industry standard?

Posted by Ameise on 01 June 2012 - 11:59 AM


I hope someone understands this:
http://www.jelovic.c...ava_is_slow.htm

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.


That is a nice article and frankly, it's got a point. However, I would like to point out that who ever wrote this is still thinking in an older mind set. Garbage Collection (GC) was a hot topic back in its birth dates just like how multi-core programming and languages that supports multi-thread optimally is a hot topic today. People back then wasn't sure if GC can be implemented on software or it needs hardware acceleration. Eventually, software was all that it needs. The point of bring this is the word "NEED". If you know your software NEEDS that 0.1s of optimization by using cache, then use C/C++ and do those crazy things! So why don't we NEED that optimization today?

The article mentioned that Java uses more memory. Is that a problem? NO...who isn't on a 64-bit machine that has more than 4096MB of RAM? Maybe people who DON'T CARE for that speed and some who just can't afford that cheap memory would still use an older system with less RAM. With that much RAM, we can AFFORD Java's heavier memory usage. Additionally, SSD are becoming more and more popular and page swapping on those isn't that bad. With that in mind, we should be focused on other things such as "Design Patterns", "Production Flow", "Prototyping" etc.

Unless you are writing some low level CORE library, honestly, WHO CARES?

CXD


Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Your point about caching seems... well, wrong. Most VM/JIT implementations tend to be relatively cache unfriendly, and that can and will significantly hamper performance. Java isn't appropriate for many games because of its system-agnostic nature - the programmer can and often will write better abstraction code than a JIT will generate.

ALSO, is there a REASON that you SEEM to enjoy PLACING EMPHASIS on things USING caps so OFTEN?

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS Posted Image


Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily point to a memory address. They point to an arbitrary object. This is why Java doesn't call them pointers - because they don't behave exactly as such. Java is still pass-by-value (just like C), but they mask away much of the functionality. Not all languages even have these pseudo-pointers - some only have concepts equivalent to C++ references, which work via pass-by-reference.




PARTNERS