RageCage
|
I'm pretty sure by a comment I read from you earlier that this is a bug.
if you have a library file called say graphics.vh and it refers to a #define that is in the system vc...
#include "graphics.vh"
#define BLAH 1
=fail
#define BLAH 1
#include "graphics.vh"
=sucess
Posted on 2004-03-17 00:58:10
|
anonymous
|
Thats not a bug. #defines can't effectively be preprocessed without an additional scan pass. .. which I could do, but thats how C/C++ works too. #defines are order dependant. They're preprocessor directives, not variables.
Posted on 2004-03-17 01:08:01
|
vecna
|
oh that was me, I just got a new computer.
Athlon64 3000+ 1gig DDR400 :D
Posted on 2004-03-17 01:09:32
|
RageCage
|
Posted on 2004-03-20 06:47:15 (last edited on 2004-03-20 06:57:21)
|
el_desconocido
|
I ported part of a C++ project into v3, including a switch that would cause verge to state that:
verbal.vc(411): "{" is not a recognized keyword or identifier.
Ironically line 411 contians only a "}".
I had default: cases and each case used {}s
I yanked out some stuff and it would compile, run other stuff fine then crash upon returning a string from within a switch.
This function will duplicate the error:
string Blah(int x)
{
switch(x)
{
case 0: return "a";
case 1: return "b";
case 2: return "c";
}
return "err";
}
I rewrote a bit and my code runs perfectly now, so that's cool. It's just odd that it compiles fine.
El
Posted on 2004-03-24 03:44:10
|
RageCage
|
I dont think strings were meant to be used as functions(I think thats the right word)
Posted on 2004-03-24 15:58:59
|
RageCage
|
all the functions around songs that deal woth position dont work. position is always 1.
Posted on 2004-03-24 16:00:12
|
mcgrue
|
I dont think strings were meant to be used as functions(I think thats the right word)
If you're referring to how El returned "err" on error, that's certainly a viable method of doing things, although you must be much more careful when using strings.
Data's data, it's how you process it that matters.
Posted on 2004-03-24 19:48:49
|
RageCage
|
I'm not sure but I believe that rotScale is causing v3 to crash the time. Either that or timer.
I have no evidence of this except before I was using rotscale it it didnt crash.
and
When I do use it, windows will give me the message, 'verge needs to close', but I can still go into verge (if I dont close that error message) and interface with everything. The only difference is that my cursor won't spin.
My cursor uses both rotscale and timer so I dunno.
Posted on 2004-03-25 04:42:40
|
RageCage
|
ok well I can safely say that it is timer that stops when it tries to exit which I guess is expected... but yeah
Posted on 2004-03-26 02:22:51
|
el_desconocido
|
Looks like SCAN_GPLUS should be re#defined as 78.
Thanks
Posted on 2004-03-28 18:13:47
|
RageCage
|
when I use map() I want to use a map thats in a sub-directory but it doesnt want to find teh vsp in the same place... and I assume its the same with the vc
Posted on 2004-04-07 00:56:08
|
reed-1
|
Here's a bug I found (I posted it in a thread, I didn't know about this thread at the time):
http://www.verge-rpg.com/boards/display_thread.php?id=10964
Posted on 2004-04-08 21:52:10 (last edited on 2004-04-08 21:52:53)
|
RageCage
|
this isnt necessarily a bug but you might want to look into it.
int batPosX;
log(batPosX);
This simply made verge crash without making any verge.log or any error... just quit. It probably shoulda said like... "string expected" or something.
Posted on 2004-04-09 02:46:00
|
vecna
|
rage... yeah, for those two reasons its not really possible to put maps in subdirs at this time, but you're absolutely right, that will be fixed.
and you're right about the string expected too. added them both to my list.
Posted on 2004-04-10 04:29:48
|
RageCage
|
heh, I bet your list looks daunting =p
Posted on 2004-04-10 05:08:02
|
Interference22
|
Ok, two bugs:
1. The "automax" CFG parameter is being ignored in the latest build of the engine. I run my game in fullscreen with automax set to 0 and yet I can still see the program auto-maximise as it changes resolution.
2. EntityStalk doesn't seem to be working quite as it should be. If you replace the Darin sprite in the Sully demo with a 32x32 sprite with hotspot data like this:
hotspot_x 8
hotspot_y 16
hotspot_w 16
hotspot_h 16
... Then Crystal bumps into the player whenever the party walks sideways, restarting her animation each time which makes it look like she's hovering. Vertical walking is fine. Bug?
This likely has something to do with the distance between stalker and stalkee. Perhaps a few more functions are in order for entity stalking, like being able to set the distance in pixels the stalker stays from the stalkee, like:
SetStalkDistance(int stalker, int stalkdist)
Or alter the EntityStalk function to accept distance input ( EntityStalk(int stalker, int stalkee, int distance) ).
... Oh, and don't forget that sound bug with one of the sound functions interpreting volume as a value between 0 and 666.
Posted on 2004-04-11 00:28:19
|
Interference22
|
Oh, and take note of the bug posted here. I wasn't sure whether it was a Maped bug or an engine one although I'm more inclined to think its an engine one: layers 5,6,7,8 and 9 aren't being rendered. I have 14 layers and they just aren't showing. Every other layer is.
Posted on 2004-04-11 00:35:04
|
ThinIce
|
I've found another problem, and I most certainly didn't code these in.
I guess you could call them 'Lazy' pixels or artifacts;
However I'm not sure if this is video card related... direct draw related or whatever but here it is (reckoning you're debugging and all)
if you download this and run it you may see what I'm talking about:
hither...
Towards the top there are some random pixels...
Here's a link to a screenshot showing this problem:
Bug.jpg
if you zoom in, you'll see a couple towards the top - left;
Posted on 2004-04-11 03:04:33 (last edited on 2004-04-11 03:19:02)
|
Macadamia
|
I was having some problems with random crashing without giving me any errors, and it took me about 9 hours to figure out some sort of solution. It appears that either freeimage does not work or some other bug happens when you create lots of image files. I was getting over five hundred image files created during the game, and about then is when it would crash (and yes, I was freeing every single one after it was used). I rewrote some of my code so I use way fewer loadimage calls, and my crashes seem to have stopped. I put some print statements testing out the values of the ints assigned to the loadimage, and even after the number was freed the loadimage would still assign an int one number higher. Not sure if that is how it is meant to be or not, but I think it would be good to allow lots of images. I can see that being an issue.
Posted on 2004-04-11 08:19:00
|