|
I'm not sure -- I'm finding it hard to visualize what you're doing. A couple notes though.
You could use an orthographic projection instead of perspective so that near and distant objects appear the same size.
On the other hand, if sorting them is the only way that will work, then the question is, how often are the chars generated? If only periodically, perhaps you could, after generating them, sort them by the y value. Then you'd have a sorted list you could walk through to render.
|
|
|
|
|
Using glOrtho instead of gluProjection worked for me. In order to make transparency work in conjunction with depth testing I used glAlphaFunc(GL_GREATER, 0.1); Luckily my textures only have a single color that needed to be transparent (white background). I appreciate your help in getting this working 
|
|
|
|
|
awesome! glad to hear its working
|
|
|
|
|
I made something similar some years ago. There is indeed two options: either go with the depth buffer as suggested by the other poster, but you'll need to find an algorithm to modify it depending on the y position of the node. The easiest would be that when you modify the y value of your character, you assign the same value to the z value.
Another option as already mentioned is sorting your nodes before rendering. This could be done quite easily by storing all your nodes in a list, and before you draw all the nodes you first sort the list based on the y value of the nodes.
|
|
|
|
|
DeviceIoControl with IOCTL_DISK_GET_DRIVE_LAYOUT does not give correct values on windows7. While it works fine on windows xp.
|
|
|
|
|
Ok, and? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
DeviceIoControl can be used with IOCTL_DISK_GET_DRIVE_LAYOUT parameter to get drives details. When i use this on windows xp it gives correct values for drive start address, drive size, hidden sectors etc. But when i run same code on windows7 the values are not correct.
How to get the correct information on windows 7. It gives me wrong information like drive start address, size etc
|
|
|
|
|
MKC002 wrote: It gives me wrong information like drive start address, size etc
Are the values just outright garbage, or maybe just some other power of 2 (e.g., 512 instead of 1024)?
What does DeviceIoControl() return?
What are you using to compare these "wrong" values against?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Has the disk got one or more mounted partitions sitting on top of it? If it has try unmounting those first and see if the IOCTL you want to use starts working. Vista added the restriction that you couldn't read and write to a disk when it has mounted file systems and this might be more of the same.
Cheers,
Ash
|
|
|
|
|
In List control, while using the Scroll bar, how we can know how much rows has went upside if scroling.
Thanks
|
|
|
|
|
guessing that the list control is in report view,
try handling LVN_ENDSCROLL notification from List control. Use GetTopIndex() to get the index of top visible item. That much rows will be on top.
|
|
|
|
|
You may use the CListCtrl::GetTopIndex, I suppose.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi!
Should I delete the pointers that are not allocated using new? While running my application, it crashes, displays the following exception:
Unhandled exception at 0x00509260 in SlogOut3D.exe: 0xC0000005: Access violation reading location 0xcdcdcdcd.
and exception pointer moves to this line:
gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
The above line is inside the constructor. Should I delete gui::IGUISkin* skin?
modified on Friday, September 3, 2010 4:36 AM
|
|
|
|
|
That looks like you're trying to use an uninitialised object of some sort.
And you only ever use delete when:
- you've newed an object
- the API you're using says you delete objects it supplies
In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Cheers,
Ash
|
|
|
|
|
Aescleal wrote: In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Can you please be a little bit exact on what I should do?
|
|
|
|
|
T.RATHA KRISHNAN wrote: Should I delete gui::IGUISkin* skin?
Normally not but you have to check what is said in the documentation.
But anyway, it seems the problem is elsewhere: did you use your debugger to see if device was created properly ? Check also the return of getGUIEnvironment and the return of createSkin.
|
|
|
|
|
T.RATHA KRISHNAN wrote: gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
How CreateSkin internally creating the object!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
what is data Serialization in MFC framework
|
|
|
|
|
Instead of writing a long description here, I suggest you take a look at this article[^] (it's part of a series of 3 articles that fully cover the subject).
|
|
|
|
|
In addition to Cédric reply, you may have a look at official documentation too "Serialization in MFC"[^] (if I remember well, isn't bad).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi all,
i m working on MFC SDI type application,when i change my DPI Settings to 120 than all application forms looks bigger than its actual size but all are properly displayed here,scrollbar is display if form is looks more bigger.
my problem is that when i saw a print preview and here Zoom the view at its maximum point and than close the print preview window now the form is display more bigger and controls are not properly displayed here.
please help me what can i do here.
thanks in advance.
|
|
|
|
|
Maybe your GDI mapping mode got changed from MM_TEXT to something else during print preview. I noticed when I used Visual Studio 2010 project generator and specified a CFormView-based class, it warned me that the printing would automatically be disabled, so there must be some funky incompatiilbity in there. I do not know what the real problem is, but based upon how you said things got all wierd, the mapping mode would be my first guess.
|
|
|
|
|
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore).
I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory.
I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
|
|
|
|
|
Sorry i can't answer your actual question, since i don't know what cool memory leak detection ways there are but i not so long ago we ran into some memory-fragmentation problems with our projects and we had to dig a bit deeper into memory management to cope with it and we leartn a few new things.
You might be experiencing slight memory usage increase because -as far as i know- CRT doesn't always "physically" free up memory when you call delete/free, it preserves some amount so it can quickly reuse it when new allocations are needed, i think it mostly does that for smaller allocations because it is more efficient that way, am not sure how you could test if this is the case or not though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
