Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jan 2001
Offline Last Active Jul 12 2016 08:12 PM

#5253543 Creating a filled Bresenham's ellipse

Posted by on 22 September 2015 - 04:39 PM

I've done this before, but with pixels. You fill spans between quadrants.
So this:
            voxelInfo.chunk.SetVoxel(xc + x, yPos, zc + z, 9, true);
            voxelInfo.chunk.SetVoxel(xc - x, yPos, zc + z, 9, true);
            voxelInfo.chunk.SetVoxel(xc + x, yPos, zc - z, 9, true);
            voxelInfo.chunk.SetVoxel(xc - x, yPos, zc - z, 9, true);
Would become something like this:
            voxelInfo.chunk.SetVoxelSpan(xc - x,xc + x, yPos, zc + z, 9, true);
            voxelInfo.chunk.SetVoxelSpan(xc - x,xc + x, yPos, zc - z, 9, true);
You also need to be careful of using 32-bit integers. They can overflow quite easily once the ellipse gets too big due to the squares. I did a test years ago. I don't remember exactly how big I had to make it before getting an overflow, but it wasn't all that large.

Here is a better ellipse drawing algorithm I've used in the past:
void FillEllipse(long left,long top,long right,long bottom)
	long		a,b,x,y,temp;
	long		old_y;
	long long	d1,d2;
	long long	a2,b2,a2b2,a2sqr,b2sqr,a4sqr,b4sqr;
	long long	a8sqr,b8sqr,a4sqr_b4sqr;
	long long	fn,fnw,fw;
	long long	fnn,fnnw,fnwn,fnwnw,fnww,fww,fwnw;

	if(right < left)
		temp = left;
		left = right;
		right = temp;
	if(bottom < top)
		temp = top;
		top = bottom;
		bottom = temp;

	a = (right - left) / 2;
	b = (bottom - top) / 2;

	x = 0;
	y = b;

	a2 = a * a;
	b2 = b * b;
	a2b2 = a2 + b2;
	a2sqr = a2 + a2;
	b2sqr = b2 + b2;
	a4sqr = a2sqr + a2sqr;
	b4sqr = b2sqr + b2sqr;
	a8sqr = a4sqr + a4sqr;
	b8sqr = b4sqr + b4sqr;
	a4sqr_b4sqr = a4sqr + b4sqr;

	fn = a8sqr + a4sqr;
	fnn = a8sqr;
	fnnw = a8sqr;
	fnw = a8sqr + a4sqr - b8sqr * a + b8sqr;
	fnwn = a8sqr;
	fnwnw = a8sqr + b8sqr;
	fnww = b8sqr;
	fwnw = b8sqr;
	fww = b8sqr;
	d1 = b2 - b4sqr * a + a4sqr;

	while((fnw < a2b2) || (d1 < 0) || ((fnw - fn > b2) && (y > 0)))
		DrawHorizontalLine(left + x,right - x,top + y,0.4,0.7,1.0); // Replace with your own span filling function. The hard-coded numbers were color values for testing purposes and can be ignored.
		DrawHorizontalLine(left + x,right - x,bottom - y,0.4,0.7,1.0);

		if((d1 < 0) || (fnw - fn > b2))
			d1 += fn;
			fn += fnn;
			fnw += fnwn;
			d1 += fnw;
			fn += fnnw;
			fnw += fnwnw;

	fw = fnw - fn + b4sqr;
	d2 = d1 + (fw + fw - fn - fn + a4sqr_b4sqr + a8sqr) / 4;
	fnw += b4sqr - a4sqr;

	old_y = y + 1;

	while(x <= a)
		if(y != old_y) // prevent overdraw
			DrawHorizontalLine(left + x,right - x,top + y,0.4,0.7,1.0);
			DrawHorizontalLine(left + x,right - x,bottom - y,0.4,0.7,1.0);

		old_y = y;
		if(d2 < 0)
			d2 += fnw;
			fw += fwnw;
			fnw += fnwnw;
			d2 += fw;
			fw += fww;
			fnw += fnww;

#5253034 collision detection in maze issue

Posted by on 19 September 2015 - 08:18 AM

My ultimate goal for this will be a little game, something like Boulderdash crossed with Pacman.

I apologize. I didn't finish my thought; it was a LONG day for me. We are trying to help you based on a very rudimentary image. Is it safe to assume that the graphics shown are simply placeholder graphics? If so, your character bounding box is far too large. In fact, it is far too large even if these are the final graphics! The collision bounds needs to be as small as possible so as to not cause false positives. There is precious little reason for your character's collision bounds to be so large as to force a collision with the environment. As it stands now, your character is always in contact with the walls. If you were to use an actual physics library, your character wouldn't move at all.

All of your problems would go away if you were to reduce the size of the blue square and you would have a much easier time if it were a circle and you did a radius collision test.

#5252945 collision detection in maze issue

Posted by on 18 September 2015 - 03:35 PM

The problem with this is that if I'm moving say left and down, it still won't go in the down direction until I stop moving.

This line needs some clarification. If the player starts moving down before being fully in the maze cell, he'll end up moving through the wall. The character MUST continue moving in the original direction of travel to clear the wall. That is, unless you plan on rotating the character, at which point you would be better off doing a radius collision test.

It would help if we knew more of your ultimate goals for this.

#5251774 Rasterizing triangle in 3D

Posted by on 11 September 2015 - 02:22 PM

I think scan-line fill algorithm is used in this case. Its idea is described on the image bellow:

The problem is that he is not rasterizing a 2D projection of a 3D triangle, but rasterizing a 3D triangle in 3D voxel space.




This is REALLY bugging me! angry.png No matter the orientation of the triangle in 3 space, it is still a planar 2D object. This *shouldn't* be hard to figure out and I'm stumped!

#5251206 [SFML] [C++] vector subscript out of range

Posted by on 08 September 2015 - 03:37 PM

Here is a way to keep the counters:

for (size_t collideCounter = 0; collideCounter < projArray.size(); collideCounter++)
	for (size_t collideCounter2 = 0; collideCounter2 < enemy.enemyArray.size(); collideCounter2++)
		if (projArray[collideCounter].rect.getGlobalBounds().intersects(enemy.enemyArray[collideCounter2].enemySprite.getGlobalBounds()))
			std::cout << "COLLIDE" << std::endl;



Yes, and that is exactly the way I used to do it until I discovered what iterators are and how to use them. I do remember reading somewhere that using indices to access a vector was either bad form or dangerous, but its been so long I don't remember where I read that or exactly what it said. Regardless, he was attempting to use iterators and doing it incorrectly. I cannot think of a good reason not to use iterators. They can get tricky if you are iterating to erase an element, but there are ways around that. They do make for cleaner code.

#5251075 [SFML] [C++] vector subscript out of range

Posted by on 07 September 2015 - 06:07 PM

But you failed to identify the obvious problems with his code. Not only that, but the issues had already been addressed and you contradicted those that had answered with the correct solution.


This is posted in "For Beginners." It can be safely assumed, just from that, that he is new to this. His poor use of iterators, coupled with him unnecessary use of counters, proved that. Reinforcing bad programming practices doesn't help him.

#5251040 Convincing AntiVirsus, im not a virus

Posted by on 07 September 2015 - 02:07 PM

I had the same problem with Avast. I had to turn off part of the program to make it stop flagging my programs.

#5251012 [SFML] [C++] vector subscript out of range

Posted by on 07 September 2015 - 11:03 AM

collideCounter = 0;

for (iter2 = projArray.begin(); iter2 != projArray.end(); iter2++) 
	collideCounter2 = 0;

	for (iter3 = projArray.begin(); iter3 != projArray.end(); iter3++) 
		assert(collideCounter2 < enemy.enemyArray.size());

		if (projArray[collideCounter].rect.getGlobalBounds().intersects(enemy.enemyArray[collideCounter2].enemySprite.getGlobalBounds()))
			std::cout << "COLLIDE" << std::endl;

Try adding this assert against the size to see if it fires. collideCounter must be within bounds, but you should use the iterator to get projArray[collideCounter] and remove the collideCounter variable.

How will the assert help? Look at the arrays. The first for loop is looping through the "projArray" vector. The second for loop is looping through... oops... the "projArray" vector again! He is then comparing "projArray" with "enemyArray", but using the length of "projArray" as a conditional for "enemyArray". Let's not forget that he is using iterators in the for loops without actually using them in his code. Look at my initial response. I eliminated the counters entirely by using the iterators for their intended purpose. The counters are redundant.

It is also recommended that you use ++iter, not iter++

You do have a point here, but even that is moot if he were to follow SmkViper's advice and use "for (const auto& item : myArray)". Using that, you get:

	//Enemy projectile collide
	for (const auto& iter2 : projArray){

		for (const auto& iter3 : enemy.enemyArray){
			if (*iter2.rect.getGlobalBounds().intersects(*iter3.enemySprite.getGlobalBounds()))
				std::cout << "COLLIDE" << std::endl;


#5250776 Need to be taught to make a 3D MMORPG

Posted by on 05 September 2015 - 08:14 PM

This is what Ive never understood. Every single person I ask how they learned to program such as minecraft modders they tell me that they "taught themselves". How the heck do you just teach programming to yourself. If programming and coding is really as complicated as all of you said it was then how does one learn just by watching a youtube tutorial and then work your self up to making an MMORPG. Do I not need a course for basic programming? Or can I just learn to make simple games then work my self up with youtube tutorials?

I taught myself, starting when I was 8. I read books. My first programs were not games, but simple text... things... Games came much later and were crude to say the least. I had learned how to write and structure code long before I even tried to make my first game and even then it looked like it was made by a child.

It can be done, but you are starting at what is the most difficult area of programming outside of OS design with no underlying knowledge of programming principles and concepts. Write a "Hello World!" program and go from there. For the time being, give up on making games. At some point down the road all that you learn will "click" and you'll get a game idea within your abilities.

#5250759 Need to be taught to make a 3D MMORPG

Posted by on 05 September 2015 - 06:01 PM

jbadams, why isn't this a topic that gets immediately locked?

#5250753 Need to be taught to make a 3D MMORPG

Posted by on 05 September 2015 - 05:33 PM


#5249781 lame question how to delete something from vector

Posted by on 30 August 2015 - 03:49 PM

Is the Erase-Remove Idiom still valid programming practice?

#5249766 lame question how to delete something from vector

Posted by on 30 August 2015 - 02:24 PM

If only there were a website built entirely around answering simple programming questions and only if there were a place you could go to ask questions and have the entire Internet scoured for answers in a matter of milliseconds.

There are many. Here is a good one that I highly recommend: http://www.gamedev.net/index

so i dont get it, does it mean i can erase something that is 1.5 from begin() then?

This is kind of bizarre! What would you expect to get 1.5 from begin()?

#5248630 Programming scientific GUI's, data and gui layout?

Posted by on 24 August 2015 - 04:06 PM

You need to separate your data from the GUI. They should not be mixed. The fact that you are displaying a floating point number or a graph of data does not mean that the GUI needs to understand the how the data is stored. You store the data in some manor, modify it and then use the GUI to display it. If you mix data storage with GUI design, then you've linked them in such a way that modifying one requires the modification of the other. This will lead to a buggy mess. You design the GUI around the type of data being displayed, but the GUI still only displays what it is given. It shouldn't care about the underlying data.

As far as the data storage issue goes, keep the original copy on disk. Load from disk and modify in memory. If you save the modified data to disk, either always save in a new file to preserve the original data, or make it a multi-step process (for safety) to overwrite the original.

Honestly, I think you are making this harder than it needs to be. I think you are too focused on the type of data being displayed. The fact that it is scientific data and not an image file or spreadsheet only dictates the fashion in which the data is displayed.

#5247313 Moving Normal Matrix Calculation from CPU to Shader Gives Me A Different Resu...

Posted by on 17 August 2015 - 11:30 PM

Post the entire vertex shader.