niyeki ama?

[Notre_Dame]

bende bir problemmi var acaba bugunlerde fazla kod yazdıım için beynim hasar görmüş olabilir...

Şimdi yukardaki durumda F10 tuşu ile ilerlediğimizde şöyle oluyor,

ama görüldüğü gibi aslında player->waypoint NULL değil.. değilmi??

[deniz]

projeyi "rebuild" at.. olmassa tüm obj leri sil.. bidaha rebuild a zorla..

[Notre_Dame]

evet yaptım. .obj dahil herşeyi sildim clean yaptım build yaptım olmadı.

[Black_Knight]

resimler niye gozukmuyor yaw??
ben sorunu anlamadım dogal olarak yardımcı olamıyorum[addsig]

[Notre_Dame]

resimler niye gözükmüyor bilmiyorum ama şöyle adres verebilirim,
http://www.geocities.com/crazysnails/1.jpg
http://www.geocities.com/crazysnails/2.jpg
hatayı buldum derleyici hatasıymış, çok iğrenç bir hata olduğunuda belirteyim;
şöyleki,
struct player_t
{
int type;
int model;
md2_anim_t anim;
int animMode;
unsigned drawflags;

bu yukarıdaki drawflags değişkenini yapıya ekleyince bu hatayı veriyor bu satırı iptal edince program düzgün çalışıyor.. drawflags değişkeninin programda hiçbiryerde kullanılmadığınıda belirteyim kafanızda soru işareti olmasın,,
bu yapı(player_t) oldukça geniş bir yapı ben bu değişkenin tanımlandığı yeri değiştirerek denedim daha aşağılarda tanımladım, şu değişkenlerin altında tanımlayıncaya kadar problem çıkardı bundan sonra problem çıkarmadı,
LARGE_INTEGER timeStart;
LARGE_INTEGER timeFinish;
unsigned int drawflags;

evet değişkenlerin LARGE_INTEGER tanımlanmış olması ilginç, hatayı çok derin araştırmadım ama araştırılsa çok somut bir derleyici hatası bulunabilir sanırım ama hiç uğraşamam ben şahsen.

[DG]

Service Pack kullanıyor musun? VC++ 6.0'ın ilk halinde çok bug var. Eğer SPleri kurmadıysam Microsoft'un sitesinden SP5.0 + Processor Pack'i edin.

LARGE_INTEGER da neyin nesiymiş (tanımlı bir sürü büyük tamsayı sabiti varken). Onun kodunu da yazıver buraya bir zahmet. Zayıf bir ihtimal ama; LARGE_INTEGER'dan kaynaklanan bir hatadan dolayı da programın sapıtıyor olabilir.

Projede, NULL macrosunun üzerine yazan birşeyler olabilir mi? Sen kendin (void *) tipinde bir deneme yaptın mı?

Eğer "Microsoft Visual C++ Toolkit 2003" senin IDEn ile uyumlu çalışıyorsa onu bir dene. VC++ 6.0'ın derleyicisi, bağlayıcısı ve böcek ayıklayıcısı (debugger) biraz *sorunlu*.

[Notre_Dame]

Hatanın kaynağını araştırmıyorum artık benden kaynaklanmadığını biliyorum bu yeterli. bendeki derleyici eski sürümlerden birisi olabilir.
LARGE_INTEGER i QueryPerformanceCounter QueryPerformanceFrequency fonksiyonlarına parametre olarak kullanıyorum.
Yalnız şu NULL a yazma nasıl oluyor biraz açarmısın..

[DG]

Service Pack leri mutlaka edinmelisin. VC++ 6.0'ın Service Pack'siz hali Quake2'yi bile derlemiyor. Sorun *büyük* ihtimal Service Packlerle ilgilidir.

LARGE_INTEGER'ı fonksiyona parametre olarak kullanma kısmını anlayamadım. LARGE_INTEGER bir tip mi? macro mu? ya da ne?

NULL bazı ortamlarda '0', bazılarında ise '((void *)0)' gibisinden boş bir gösterge olarak tanımlanmış olabilir. Senin programın kaynak kodu içinde de NULL #undef sonra da #define marifeti ile değişmiş olabilir. Tam emin olmak için player->waypoint 'i (void *) ve ((void *) 0)'a karşı da dene.

[HakanNehir]

direk
unsigned drawflags
yerine
unsigned int drawflags
ya da
unsigned veri_tipi drawflags
denedin mi ?


yine hata veriyor mu ?

[leblebi]

Hata senden kaynaklaniyo!!! Bir yerde heap'i corrupt ediyosun onun icin struct'in buyuklugunu degistirince hata gidiyomus gibi oluyo.

Visual c'nin boyle basit konularda hata yapacak compiler oldugunu sanmam.

[Notre_Dame]

Quote:

On 2004-04-27 19:42, leblebi wrote: Hata senden kaynaklaniyo!!! Bir yerde heap'i corrupt ediyosun onun icin struct'in buyuklugunu degistirince hata gidiyomus gibi oluyo. Visual c'nin boyle basit konularda hata yapacak compiler oldugunu sanmam.

leblebi gösterdiim resimlere baktınmı?structun büyüklüü değişmiyor sadece struct içinde tanımlı ve hiçbiryerde kullanılmayan zalak bir üye değişkeninin tanımlandığı yeri değiştirince program düzgün çalışıyor.
bendeki visual c++ gayet hatalı bir program bu tür hatalarla daha öncede karşılaşıyordum ama obj. leri ve diğer çıktı dosyalarını silip tekrar derlediğimde hata felan kalmıyordu.
DG : service packı indirsem iş çözülebilir belkide ama heralde o pack en az 30-40mb felandır şimdi hiç kasamıycam dialup ile.
LARGEINTEGER 64 bitlik bir tamsayı tipi, her makina derleyici desteklemiyor galiba
şöyle tanımlanmış MSDN den..

typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
HakanNehir: Çok incelemedim ama değişkenin tipini yada adını değiştirincede hata devam ediyordu.

[DG]

Service Pack 5, 130MB Internet Cafelerin birinden çekip CD yaptır bence. İnan bana bu güncellemeye ihtiyacın var. Ya da direk VS .NET'e atla.

Çok suni bir çözüm olur ama:
Gerçekten 64-bit bir tamsayı değişkenine ihtiyacın olduğuna emin misin? unsigned long ile parça parça depolayabilirsin değişkenini. Mesela saatleri bir değişkene, dakikaları bir değişkene vs.. Ya da her neyi parçalara ayıracaksan.

[mentat]

cok uzak bir ihtimal ama.. release modda debug etmeye calisiyo olabilir misin?

olamazsin di mi?

[leblebi]

Resimlere baktim yaw.

Bak simdi derdimi anlatiyim sana. Soyle bi kod dusun

struct t_hebele
{
int dummy;
int dummy2;
}

void fonk ()
{
int arr[2];
t_hebele hubele;

// burada kod baslar acayip komplex seyler yapar

// sonra dalginliktan yada bi bugdan array'in size'ina yanlis access yaparsin:
arr[3] = 1234;

// burada komplex seyler devam eder
}

Simdi eger hubele'yi hic kullanmiyo olsan bile eger compiler optimize etmediyse (ve tabii ki compiler'ina gore cunku alignment vs. gibi seylere dayanarak variable larin adresleri degisik sekilde ayarlanabilir ve hatta swap bile edilebiliyolar) hubele orada kalir ve senin arr[3] seklinde access etmen hicbi sorun yaratmaz. ok?

Yani hafizada soyle durma ihtimali var:
[arr0][arr1] [hubele.dummy][hubele.dummy2]

Boyle olunca senin arr[3] hebele.dummy2'nin ustune gelmis oluyo. Dedigim gibi boyle durmak zorunda degil, ama boyle durma ihtimali var. En azindan con sayida degisken kullanirsan out of bounds array access yaptigin zaman degiskenlerin birbirinin ustune gelme ihtimali de yuksek olacaktir.

Senin soyledigin problemi yeniden olusturmak icin, ornegin "ben dummy2'yi hic kullanmiyorum, bari onu kaldiriyim" dersek, o zaman program access hatasi yapmaya baslar vs. vs. Alakasiz bi problem alakasiz bi sekilde karsina cikmis olur.

Heap'i falan corrupt ettigin zaman debugger iyi degilse(yani "hoop heap'i corrupt ettin" diye seni onceden uyarmamissa) zaten debug olayina guvenemezsin.



[ Bu mesajı düzenleyen: leblebi _FIL 28-04-2004 19:43 ]

[Notre_Dame]

sensei nin kodunu denicem daha sonra belkide hata bendedir bilmiyorum..