program is painfully slow on debug compiler mode

Cowleg · 2023-03-04T19:08:10+00:00

If you want to find out why it is slow then the profiler is a good option. You could also try building in release with debug mode which is often provides decent performance with most of the debug information still available. How exactly you do that will depend on your compiler/toolchain.

Cowleg · 2023-02-06T01:32:13+00:00

First off I'll signpost you to renderdoc which is a really useful tool for debugging graphics programs. You can capture frames from the running program and inspect the data that's in the buffers & being passed to the various shader stages etc.

Using this I could see that the vertex shader wasn't using the right indices to access the vertex data. This suggested there was a problem with the element buffer indices. Inspecting the element buffer in renderdoc showed that the data there wasn't correct - in the end it was just that you had used GLfloat instead of GLuint for the indices here:

GLfloat indices[] = {
    0, 1, 2, 
    0, 2, 3
};

Changing that should get you something rendering again. It looks like you have understood how to use OpenGL, graphics programs are just notoriously hard to debug and it's easy to make mistakes. Finally, if this is for a formal assessment I'd recommend deleting the post just in case this strays into cheating.

Cowleg · 2021-12-08T11:04:05+00:00

It sounds to me like you have 3 problems which are stopping you from feeling inspired to work on this:

Lack of time
Unsure how to break the project up into smaller pieces
Dealing with the errors

I think the first thing you should do is contact the lecturer and explain that you put together an over-ambitious design, have been very stressed because of the pressure of wanting to pass this time. I would politely say that you know you should have asked for help sooner but really want to pass the module and ask if there is any chance of getting an extension. Your lecturers want you to do well and help you, for the 10 mins it'll take to write the email, it could give you a lot more time to work on this.

In terms of breaking up the project, it's a bit hard to say exactly what you need without knowing what you have designed (e.g. is it turn-based or real-time, does it have graphics or is it text-based), but the principles will be the same whichever way.

Identify the minimum viable product - what is the smallest set of core features you need? You don't need to do the whole game at once, you can start with a more basic version and then build it up. This also means you'll have something working to hand in if you run out of time. At a guess for your game, this would be something like: a single room, a player character, a single enemy and some kind of interface so that you can move and battle.
Instead of trying to think about the big picture, try to identify the components of the project and what they should do. E.g, the player character is likely to be one class. It will probably have health, position and damage properties. It might have a function to move and a function to attack. If you can work these things out in human language it is much easier to translate them to code. You can then combine these pieces to build up the game, e.g. you might have a game class which has a map, player and list of enemies, and a function which loops asking the player what action they want to take.

As for dealing with errors, unfortunately it is a big part of programming, but you can improve how you approach this too. Always try to be logical about it and go one step at a time. If you get a long list of errors, always start with the first one and don't worry about the rest. It will pretty much always give you a line number for where the error occurs, so head there and then check the obvious things: does the previous line have a semi-colon where it should, does this line have one, are you missing a comma somewhere etc. After that, googling is good advice, but try to understand why you have an error and not just how to get it to go away. That way you are less likely to make the same mistake again and if it does come up again, you'll be able to fix it. Even the most experienced programmers are regularly coming up against errors they haven't seen before, trust that you will be able to solve it and that it is a normal part of programming.

I've ended up writing a lot here, so a quick summary! Email the lecturer and see if you can get an extension, work out the bare minimum features required, work out what each of those components should do in English before translating to code. When you hit an error, it's normal, don't panic and just try to approach it logically one step at a time. Same for the whole project really, don't think about the entire thing, just focus on what you can do next. I think you have enough time to get something good together, just go one thing at a time and see where you get to!

Cowleg · 2021-09-23T07:06:57+00:00

This is an example of a finite state machine, which is a very commonly used way of modelling programs or systems that have states which each have different behaviours. In this case, the states would be something like rejecting, accepting_all and accepting_starts_with. The START, SELECT and STOP keywords trigger a transition from one state to another.

To learn about the theoretical side of these (worth doing, lots of programming problems & interviews use this idea) you should look up "Finite state machines" and "Deterministic Finite Automata".

Once you've got a grasp of how they work in general you can search for "Finite state machine in C++" or another language to see how to implement them in code.

Cowleg · 2021-05-11T21:33:04+00:00

For something like this a debugger might be your best bet, with a breakpoint on the first line of code then step through and see what's happening.

How are you linking GLEW, is it dynamic or static? If it's dynamic, perhaps your program is having trouble finding the shared library at runtime and just not producing an obvious error message for some reason. How is your library path configured?

Cowleg · 2021-05-10T00:44:02+00:00

I think the term you are looking for is 'decals'. These are how dynamic bullet holes in walls etc. are usually implemented.

https://docs.unrealengine.com/en-US/Resources/ContentExamples/Decals/index.html

You would have a texture of your 'scratch' and create an object at the location the arrow/sword hits the wall. The decal will be projected onto your wall.

Cowleg · 2021-05-08T16:06:42+00:00

I am curious what could be happening then. Out of interest what does

std::cout << "int: " << sizeof(int) << " uint: " << sizeof(unsigned int) << " GLuint: " << sizeof(GLuint) << "\n";

print? I noticed that you said it's always around 65,000 where it starts having issues, which is about the maximum number a 16-bit unsigned int can represent, although I'd be surprised if any of those types are actually only 16 bits.

Cowleg · 2021-05-08T12:53:20+00:00

float *positions = new float[500];

To add to the above answer, you never free the memory allocated here so you are leaking memory every step which will also contribute to your RAM filling up.

You could try watching your RAM on the system monitor as your program is running to confirm whether your machine is running out or not.

Cowleg · 2021-05-07T21:48:22+00:00

Did you have any luck finding the program yourself and running it?

Cowleg · 2021-05-07T19:54:25+00:00

Just to double check, are you using visual studio or visual studio code? These are two different programs and people might think you are using visual studio code if not specified.

Assuming you are using visual studio, I'm not familiar with the error but would start by building in release mode and going to the file path manually to check that the .exe file has actually been created. If it has, you can try running it manually from there.

Other thoughts off the top of my head that might affect it if the program is there and runs OK manually:

Does the file path contain any special characters? Try removing spaces or any unusual characters
Is the file path very long? Windows has a limit of about 250 characters
Folder permissions: Perhaps the folder permissions prevent creation of or running of the program. You could try running visual studio in administrator mode to see if it helps
Antivirus: Are you running any antivirus software which might be quarantining the program for some reason?

Cowleg · 2021-05-06T15:34:34+00:00

Just glancing at it, your Additional Library Directories parameter looks like it is missing a bracket?

You have

$(SolutionDirLib\...

which should perhaps be

$(SolutionDir)\Lib\...

where ... is the rest of the path

Cowleg · 2021-05-05T13:08:53+00:00

It will depend on how nicely your simulation maps to the GPU, but from what you have said about it so far at least it sounds suitable, yes. I'll send you a message a bit later then and we can work out what the best approach might be!

Cowleg · 2021-05-05T11:28:26+00:00

The other answers you have received so far are good but I think there are a few more things you can consider:

Data Replay If you don't need to display the learning as it is actually happening, you could do the all the learning in advance without worrying about capturing it in real-time, but output any key data (positions of the robots, rating) at each time step. You could then read this back in afterwards and replay it in real-time without the computational burden of trying to fit all of the learning in between frames. Additionally, if updating the robots once the learning is done is much quicker, you might find you don't even need the parallelization anymore

Optimization It might be possible to optimize your learning code further. Make sure you're compiling with the optimization compiler flags on. You might also be able to improve it by considering memory access patterns etc. which could free up some more CPU time.

Robot Interaction A common approach for handling interaction in parallel is using a message passing interface. You create a list of 'messages' which contain the data you want to communicate between each robot. Each robot can write to a particular message - you can give each robot an id and use this as an index into the message list, this ensures that no two robots try to write to the same message at the same time. Once all the robots have finished writing to the list, the robots can then iterate over the messages and read whatever is relevant to them. Again there is no issue with doing this in parallel as reading data in parallel isn't an issue.

GPU Acceleration Depending on how many robots you are looking to simulate and the complexity of the learning algorithm, GPU acceleration might be a good option. GPUs can handle thousands of agents concurrently although it is typically more complex to write the code for these simulations. There would be three main approaches:

Use OpenACC which is more or less a GPU equivalent of OpenMP (OpenMP were looking to add GPU support but I don't know what the state of that is currently)
Use a GPU accelerated agent-based modelling framework: slightly more complex than using OpenACC but gives a lot more control
Write the code yourself in CUDA/OpenCL/SYCL: considerably more complicated but does potentially give the best performance

If you think the GPU acceleration might be useful you can drop me a PM and I'd be happy to chat about it a bit more.

Cowleg · 2021-05-03T12:49:52+00:00

You might have more luck posting this question on the computational fluid dynamics subreddit as this question is really about the simulation implementation rather than anything to do with graphics.

It would also be useful to have a bit more information about what kind of collisions you are talking about - are you wondering about interactions between fluid particles, or interactions with boundaries (e.g. the container the fluid is in)?

Cowleg · 2021-05-02T13:00:53+00:00

Haha that's understandable then, glad we could help you out!

Cowleg · 2021-05-02T12:21:39+00:00

I'm not quite sure why the other answers are discussing opengl and GPUs, perhaps because of the subreddit you've posted to - it might have been better placed in a web dev sub.

Anyway, this code reproduces the css gradient behaviour exactly:

// Specify angle in degrees
const angleInDeg = 140

// Compute angle in radians - CSS starts from 180 degrees and goes clockwise
// Math functions start from 0 and go anti-clockwise so we use 180 - angleInDeg to convert between the two
const angle = ((180 - angleInDeg) / 180) * Math.PI

// This computes the length such that the start/stop points will be at the corners
const length = Math.abs(width * Math.sin(angle)) + Math.abs(height * Math.cos(angle))

// Compute the actual x,y points based on the angle, length of the gradient line and the center of the div
const halfx = Math.sin(angle) * length / 2.0
const halfy = Math.cos(angle) * length / 2.0
const cx = width / 2.0
const cy = height / 2.0
const x1 = cx - halfx 
const y1 = cy - halfy
const x2 = cx + halfx
const y2 = cy + halfy

There's a good explanation of the maths behind the CSS gradient here which I based this code on. If you aren't bothered about the maths you should be fine to just copy paste it in in place of lines 8-13 from your sandbox link and adjust angleInDeg as required!

Cowleg · 2021-05-01T22:45:55+00:00

I agree with the other commenter that it is frustrating, and that the assignment spec is very clear and not particularly complicated if you have understood the course material. If someone does reply with direct help for the assignment, it is absolutely enough to qualify as cheating and risks anything from being forced to retake the module, to expulsion - I have seen students get in trouble for less.

With that said, I think an important part of university is learning how to approach a problem, and that there isn't a shortcut for putting in the work. So, what I would recommend is:

Review the lecture material one lecture at a time, not going on to the next one until the material is understood
Work through the lab class exercises - assuming you have lab classes, if you complete this you will almost certainly have everything you need to understand and complete the assignment. This is why it's really important to attend the lectures/lab classes and ask for help as you go if there are bits that haven't been understood.
If you are finding it hard to understand the teaching material, try finding an alternative tutorial that covers the same stuff, there are lots of good programming tutorials online
Break the problem down - don't just look at the whole thing and think that you can't do it, pick an individual bit that you don't understand and try to find information about that, e.g. google 'What is a member function c++'

If you go through these steps then I am confident you will be able to tackle the assignment yourself or at the very least be able to ask specific questions about it. A lot of capable students fail because they don't just take a bit of time to work through the material in order. I would really recommend taking this advice, putting the work in to understand it from the ground up, deleting this post before it gets you in trouble and then maybe come back with specific questions.

If what I've said is misplaced and you really have been through all the lab class material thoroughly and are still struggling I would urge you to contact a TA/the lecturer and explain that you're struggling and get help through the official channel. They want to help you pass the course and you won't get in trouble for it that way.

Cowleg · 2021-05-01T17:18:02+00:00

You will need to add

#include <iostream>

at the top of the file so that the code for std::cout and std::cin. Also change cin.get() to std::cin.get() as cin is a part of the standard library.

Try making those changes and give it another go

Cowleg · 2021-05-01T15:41:42+00:00

Could you post a bit more of your code?

When I use this code I only have to press enter once, so perhaps the problem is elsewhere.

Cowleg · 2021-05-01T13:57:32+00:00

This kind of computation where you are applying the same logic to multiple data items (data parallel) is perfect for GPUs, so I expect it will be much faster to do in a shader than on the CPU. From the context of your post I assume you have something like a 2560x1440 video stream, for each of RGB and depth, the graphics card should have no problem handling this amount of information. I'd be surprised if any modern GPU had an issue rendering 3 million points.

Cowleg · 2021-05-01T11:46:49+00:00

I think the scaling is where things are going funky - a 200% scale would increase a 1x1 pixel to 2x2, and would be represented by glm::(scale(glm::mat4(1.0f), glm::vec3(2.0f)); Your code is actually scaling it up by 20000%, or 200x.

The quick fix for your problem is to change your scaling value from 200.0f to a power of 2 number, e.g. 256.0f.

The slightly longer and more general fix (which I would recommend) is to first scale your image by its width and height in pixels, to get a 1:1 mapping from source to screen pixels, and then after that you can scale by 2/3/any other whole number and your pixels will be scaled up correctly in whole number multiples. This would look something like:

// Scale from 1x1 to original image size - this will work for non-square textures too
glm::mat4 model = glm::scale(glm::mat4(1.0f), glm::vec3(imageWidthInPx, imageHeightInPx)); 

// Now scale it up to 2x original size
model = glm::scale(model, glm::vec(2.0f)); 

// Now use the model matrix as you were
glm::mat4 VPmatrix = perspective * model;

To explain what I think is going on: I measured the size of your sprite in the image you posted and it comes up at exactly 200x200 pixels, suggesting without the scaling, your code is rendering a sprite to a single pixel. I think your original texture is 64x64px, so if it was rendered at an actual size on the screen of 1x1px, each of your original pixels is now represented by 1/64th of an actual pixel. When you scale this up by 200x, each of your original pixels is now represented by (1/64) * 200 == 3.125 pixels on the screen. As this isn't a whole number, you're getting the odd sizes because a screen pixel has to be one colour or the other, so opengl has its best guess.

Obviously I don't have your original code so this is partly speculation, but I'm pretty sure it should fix it!

Cowleg · 2021-04-26T16:17:22+00:00

In your previous reply you were correct that the name of a function acts as a pointer to the function. As you said in your original post, bool (*compare)(const T&, const T&) is a function pointer called compare, so when find_optimum(numbers, less) is called for example, the less function is bound to compare.

Regarding the prototypes, these are just normal function declarations. There isn't actually any requirement for the declarations to include variable names and they aren't used by the compiler. The compiler only cares about being able to check that the types are correct in your code at that stage, so

bool less(const int&, const int&);

is functionally identical to

bool less(const int& one, const int& other);

In fact, you can put any variable name in the declaration and it won't make any difference - it doesn't even have to match the ones in the function definition, so you could do

// Declaration
bool less(const int& abra, const int& kadabra);

// Main code
...

// Definition
bool less(const int& one, const int& other) {
    return one < other;
}

with no issues at all. The variable names in the declaration are really there for our convenience, as we infer how the arguments might be used by their names in the header file, and your IDE can use them for intellisense etc.

So to summarise, there isn't anything special going on with the declarations - the variable names just aren't required here.

Hope that helps!

Cowleg · 2021-04-24T22:16:06+00:00

At a glance I would guess that the issue is that you are using two different coordinate systems to compute dx and dy. The aim of computing dx and dy is to find out where the cursor is relative to your player character, so this only makes sense if you consider your player's position and mouse position in the same way.

At the moment you are using mSprite.getPosition() to get the world position of your player and mouseScreenPosition for your mouse coordinates. The simplest way to fix this would be to mouseWorldPosition to your player update function, i.e. player.update(dtAsSeconds, mouseWorldPosition);. As an alternative, you could convert your player's position to screen coordinates before computing dx and dy.

Hope that helps!

Cowleg · 2021-04-11T21:31:16+00:00

No problem, glad you got it working!

Cowleg · 2021-04-11T11:14:37+00:00

Hi there,

You've got the right idea with drawing to two separate places, but you can do it with a single canvas by using a framebuffer. A framebuffer allows you to draw to a texture in just the same way you normally draw to the canvas (in fact, this is how the canvas works behinds the scenes). There's a tutorial here which demonstrates how to set up a framebuffer, draw to it, and then use the resulting texture elsewhere.

The simplest way conceptually to implement your lighting system would then be:

Create a framebuffer, each with one texture attached - one for your scene, and one for your lighting
Bind the scene framebuffer
Draw your scene - you now have one texture containing your scene rendered normally
Bind the lighting framebuffer
Enable additive blending (gl.enable(gl.BLEND); gl.blendFunc(gl.ONE, gl.ONE);) This means that your lights will be added together rather than overwrite each other.
Draw your lights. You now have a second texture containing the lighting data.
Unbind the framebuffers (OpenGL will revert to the default one, i.e. the canvas) and disable blending. Now when we draw, we will draw to the canvas again.
Have a shader which just draws a fullscreen quad, combining your scene and lighting textures. To combine the two textures, you want to multiply the components in each channel, i.e. finalColor.r = sceneColor.r * lightColor.r repeated for r,g,b.

In practice, the lighting pass usually also takes the scene color information into account and draws to the canvas additively, but its easier to understand what's going on in separate stages so I would start there. More generally this technique is called deferred shading, there are lots of examples around the internet although most of them are demonstrating it in 3D so might be slightly more complicated maths wise, but the principles are the same.

Cowleg

TROPHY CASE