Användarprofil

Uppgifter
Användarnamn
Email
Besök -
Hemsida Ingen
Plats (stad)
Senaste besök 01:00 - 1:a Januari 1970
Poster i forumet
Varningar
Grupp
Medlem sedan 01:00 - 1:a Januari 1970
Artiklar och filer
Den här användaren har inga artiklar eller filer

Avatar


Presentation av

Den här användaren har inte skapat någon personlig presentation.

Senaste inläggen i forumet

c++ problem
lägg till
using std::cin;
längst upp under/över using std::cout;
så funkar cin.get();
alternativt kan du skriva
system("PAUSE"); istället. (om du använder windows iaf)

Postad 09:38 - 14:e Januari 2009
pixelperfekt collision
Funkar nu, var det som var "fel" perfekt, tack för all hjälp!

Postad 15:47 - 7:e Januari 2009
pixelperfekt collision
Jag testade att ta bort "väggarna" och skriva ut 1/0 om den registrerade kollision, märkligt nog så gjorde den inte det hela tiden, och ibland en bit utanför spriten ( ovanför, typ små trapsteg som sticker ut från spriten).
jag kör för enkelhetens skull med två sådana (den blev lite av kapad när jag klippte ut den från bilden), den ska egentligen vara 64x64.

Den enda större skillnaden jag kan se, är att jag fyller cirklarna med 1:or, respektive 2:or (om jag skulle använt ett snarlikt sätt för att rita upp det).

och att jag fick använda 
  1. extern "C"
  2. {
  3.  #include "bitmask.h"
  4. }

annars gnällde VS2008 hela tiden, tydligen var det nåt om att kompilatorn inte kunde "blanda" C och C++ kod annars, eller nåt snarlikt var det iaf. Borde inte göra nån större skillnad tycker man.

EDIT:
fast vänta nu...

Tror fasen jag kommit på det nu. Blir till att försöka få rätt på detta på tåget.
Eftersom mSprite->GetTexture() returnerar hela sprite-sheet:et så blir det inte "ny" rad när 64 tar slut (där sprite:n slutar), utan vid 256 istället, så DWORD *color kontrollerar antagligen på fel ställen i setHitTable-funktionen, kan det vara så helt enkelt? Måste ta mig tusan vara så, det skulle förklara mycket, då rapporterar den nog större delen av spriten som icke kolliderbar. Detta måste jag undersöka alltså!

sprite sheet:et där jag klipper ifrån ser ut så här (det är en bild):

Alltså jag tror nästan det måste vara det här som spökar. Ska nog posta på HGE och höra ifall det verkligen är tänkt att getTexture ska funka så, kan vara en bugg i resurshanteraren kanske.

Postad 09:46 - 7:e Januari 2009
pixelperfekt collision
Fasikens, den ska funka har räknat pixlar nu också, den går in i bitmask_setbit varje gång som alpha är skilt från 0.

min kod för att jämföra:

  1. void gameobject::setHitTable()
  2. {
  3. 	DWORD * indexColor = hge->Texture_Lock(mSprite->GetTexture(), true);
  4. 	int width = mSprite->GetWidth();
  5. 	for(int y = 0; y<mSprite->GetHeight(); ++y)
  6. 	{
  7. 		for (int x = 0;x<width;x++)
  8. 		{
  9. 			DWORD *color = &indexColor[x+y*width];
  10. 			if((GETA(*color) != 0))
  11. 			{
  12. 				bitmask_setbit(mHitTable, x,y);
  13. 			}
  14. 		}
  15.  
  16. 	}
  17.  
  18. 	hge->Texture_Unlock(mSprite->GetTexture());
  19. }


,,ndrade tillbaka från textureWidth/height, då jag klipper ut sprite:s från en större bild, så blev bredden 256 istället för 64, samma sak med höjden.


min kod för jämförelse:
  1. bool gameobject::isCollidingPixel(gameobject* collObj)
  2. {
  3. 	if(isCollidingBox(collObj))
  4. 		return bitmask_overlap(mHitTable, collObj->getCollisionTable(),
  5. mPosX -  collObj->getPosX(), mPosY -collObj->getPosY()) != 0; 
  6. 	else 
  7. 		return false;
  8. }

dokumentation om bitmask_overlap:
  1. /* Returns nonzero if the masks overlap with the given offset. */

Och om hur den räknar offset står här enligt dokumentationen:
  1. The overlap tests uses the following offsets (which may be negative):
  2.  
  3.  *
  4.  *   +----+----------..
  5.  *   |A   | yoffset   
  6.  *   |  +-+----------..
  7.  *   +--|B        
  8.  *   |xoffset      
  9.  *   |  |
  10.  *   :  :


Kanske skänker ytterligare lite ljus över mitt problem och kanske en eventuellt lösning, men jag hittar ingetSmiley

(letar fortfarande alternativ om jag inte hittar en lösning på detta snart, börjar tröttna på att "leka" med detta nu)

tack på förhand.

Postad 19:57 - 6:e Januari 2009
pixelperfekt collision
Funkar tyvärr inte som tänkt, har ingen anning vad som gått fel, den rapporterar krock någorlunda korrekt om man går med sprite:en uppåt eller neråt mot föremålet man ska krocka med, men kommer man från höger eller vänster så skiter det sig. blir små hack på sina ställen om man kommer uppifrån/nerifrån, och vid de yttre kanterna så åker den rakt igenom det den ska kollidera med. Kommer man från sidorna åker sprite:n rakt igenom kollisionsobjektet.Smiley

tycker den borde rapportera krock även om sprit:en är mitt i den andra sprite:n (vilket den är när den åker rakt igenom).

Kan det vara skillnad på spritensstorlek och texturensstorlek? Det borde vara samma ifall ja inte modifierat sprite:n och/eller texturen. (ska testa byta till texture height etc... istället för sprite height)

t.ex. denna Balloon fight så nåt måste jag ju göra fel, har skickat ett meddelande till personen i fråga (som gjort balloon fight) får se ifall jag får svar. Hoppas på det, såg att han använde version1.7 alpha av bitmask biblioteket.

Finns det några andra små kollisionshanteringsbibliotek där ute? Helst som funkar tillsammans med hge och fortfarande har support?

tack för all hjälp hittills!

Postad 18:38 - 6:e Januari 2009

Skicka meddelande
Läs s blog