Statemanager.cpp
Pastebin.pl is a website where you can store code/text online for a set period of time and share to anybody on earth
Statemanager.h
Pastebin.pl is a website where you can store code/text online for a set period of time and share to anybody on earth
I will leave the link below for you to check the dx9 files https://cdn.discordapp.com/attachments/1042535523413135491/1052623450453327922/Directx9-Update-main.zip
Besides learning programming you also need to learn the debugging skill. That skill is about how to find out why your program is not behaving as you thought.
It's a highly creative skill. With enough practice and understanding of your code you can find the source of the trouble very quickly.
Some approaches are:
Other tactics are to write unit tests for the critical parts of your program so you can eliminate some areas of the code as source of the bug. In general though you should do that before using the critical code.
@undefined The codes she gave are clear, I'm stuck here.
(Press Retry to debug the application - JIT must be enabled) CStateManager::RestoreTextureStageState - This texture stage state was not saved [0, 5]
Assertion failed!
Program: ...k\Desktop\Client Source dx9\binary\Me.exe
File: C:\Users\burak\Desktop\Client Source...\StateManager.cpp
Line: 559
Expression: !" This texture stage state was not saved!"
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts
(Press Retry to debug the application - JIT must be enabled)0x3010 iş parçacığı 0 (0x0) koduyla çıktı.
You're looking at the wrong spot for the answer.
“AssertionError” simply means “I detected something very wrong, I can't go further.” That's report is not telling you the cause, it's telling you the result of something that happened or didn't happen before detection of a major problem.
Imagine you have a car, it's a bit old, but it's all working fine as far as you can see. So you're happily driving at the road and then suddenly the car breaks down, You manage to put it safely at the side of the road, open the cover and find the engine is too hot. You're stuck.
Now imagine you can go back in time and try that again. Again the car seems fine, you're again happily driving at the road, again the car suddenly breaks down with a too hot engine. Again you're stuck. You however don't get new information WHY the car is running hot.
You can stare yourself blind at the resulting disaster, but the answer to the problem is not there. Something in the code before did or didn't do something that apparently you need at the point of the crash. To get forward in solving this problem, you need to find out what that “something” is. The message of the error is probably trying to tell you the problem it found, so that seems like a good starting point to me.
Find out what “texture stage state” means, check in the code what you did with it. Find out what “saved” means of such state and how you do it. “[0, 5]” no doubt also has meaning. If you read line 559, you may be able to figure out what texture stage state it refers to.
EDIT: As a more concrete example, consider this code:
def distribute_message(self, msg):
if self.busy:
# Already running, just queue the message.
self.queue.add(msg)
return
# First message.
self.queue = []
self.busy = True
count = 0
while True:
# While messages exist do
subscribers = self.channels.get((msg.sender.name, msg.mesg_name))
if subscribers is None:
print(f"Warning: {msg} has no channel.")
else:
for sub in subscribers:
sub.recv_message(msg)
if not self.queue:
break
# More messages to deliver.
msg = self.queue.pop()
count = count + 1
assert count < 100, "Infinite message loop detected."
self.queue = []
self.busy = False(Start reading at “First message”.) It sends a message to subscribers of a channel. However, as we send a message those components may reply with another message, so this code must queue those messages and deliver them after the first message is done.
As you can see there is a “assert count < 100” here. It protects against 2 components sending each other new messages infinitely since after delivering 100 messages the assert crashes the application. Now if such a crash happens, the problem is not here, it's in how the components are coded (as in, they should not always reply with a message, but behave differently).
The assert just warns me about this problem, I have to figure out what components are involved, and decide how to change them.
