mcgrue
|
http://vecna.verge-rpg.com/v3vergec.txt
Yeah, thats in.
But where's MakeGame() ?!!!?!!!!!@11
Posted on 2004-04-13 00:04:12
|
sabernet
|
int good;
if(time == plenty)
{
MakeGame(good);
}
else
{
BlowUpBrain();
}
(keep in mind, I dunno v3vc yet^^;)
Posted on 2004-04-13 04:31:31
|
mcgrue
|
omg. BlowUpBrain() needs to live.
Posted on 2004-04-13 04:45:28
|
sabernet
|
the function that lives to see you die^~
Posted on 2004-04-13 23:05:01
|
Gayo
|
I find iut mildly vexing that the player moves faster diagonally than veritcally or horizontally. Technically, in the time it takes a character to move one tile horizontally or one tile vertically, he should move something like 0.71 of a tile vertically and horizontally...I think. It's just slightly annoying since it means that in any place where time is important, walkins diagonally allows you to "cut corners".
Posted on 2004-04-20 07:04:31
|
vecna
|
I'll play around with it. I originally had you walking at the correct speed diagonally, however it caused problems with losing sync with party followers, but that was before I switched to my current party following system.... which SHOULDNT screw up.
Posted on 2004-04-20 12:59:49
|
Troupe
|
Are you telling us you haxed v3 just so you could get your party follow system to work Vecna? Talk about cutting corners...
Posted on 2004-04-20 14:12:15
|
rpgking
|
I noticed in quite a few console games that have pixel-accurate movement, the characters are faster when they walk diagonally...
Posted on 2004-04-20 15:08:59
|
Omni
|
That's because...
walking one pixel a second horizontally,
walking one pixel a second vertically,
When doing both, you really are walking two pixels a second, which is faster than either alone. It's weird if you think about it, but it's not a problem. I'd sacrifice proportionally correct pixel-walks for party following too.
Posted on 2004-04-20 23:51:02
|
Overkill
|
A suggestion: How about a following system that makes entities chase a target without waiting for them to move? This would be useful for enemies and such, because they will rarely reach the player if they only move when the player moves.
Posted on 2004-04-21 02:44:14
|
mcgrue
|
entity.trueDiag = 1/0; maybe?
</stab_in_the_dark>
Posted on 2004-04-21 06:37:43
|
Troupe
|
The main question is, do you get any extra speed by zig-zagging. If you can go faster just by moving right and left whie going up, then you have a problem. If the speed is scaled to the distance its ok.
Posted on 2004-04-21 13:45:30 (last edited on 2004-04-21 13:54:25)
|
rpgking
|
As of now, it does go faster. Don't see it as much of a problem though...
Posted on 2004-04-21 15:08:55
|
Troupe
|
Thats a huge problem in timed segments. Unless you want zig-zagging to be just another "tactic" that the hardcore gamers use to increase their speeds.
Posted on 2004-04-21 17:39:47
|
vecna
|
This isn't quake 3 exactly. ^_^ As it stands, programmed entities don't go diagonally anyway - and although you move too fast presently, even at the correct speed, moving diagonally is still faster.
It takes 16 ticks to cross a 16x16 tile diagonally right now.
It would take 32 ticks to cross the tile by going left and then down.
It SHOULD take approximately 22 ticks to cross the tile diagonally.
Incidentally, the main reasons that programmed entities can't move diagonally is that the pixel accurate collision checking performed on the player entities is much more cpu intensive than whats done on the normal entities, which is already a bit expensive (in order to accomodate multiple entity hotspot sizes - every pixel contact surface has to be checked) and I hope to optimize later. Bumville, if you try to use the speedup key, is a good example, on my 1.2ghz the entity collision checking was too much for the speedup key. So I'm very reluctant to make it even slower by applying the full collision checking to every entity.
Posted on 2004-04-21 18:38:08 (last edited on 2004-04-21 18:38:48)
|
Gayo
|
Is it that much of a speed hog? Hm. Sometime in the distant future it might be neat if there were a config option to ignore chr hotspot sizes (though not locations) and set all hotspots to a predefined size, or set them all to 16x16, or some multiple of 16x16, or something like that.
Posted on 2004-04-21 20:08:43
|
vecna
|
yeah, the combination of pixel-accurate movement (needing obs checking each pixel instead of each tile) and variable hotspot sizes, increased the number of comparisons per entity per tick from 1, to, a really big number. And it gets worse on uh I guess exponential basis as entities are added. There is some optimization I can do, and I'll get around to it eventually. But for now, it works.
Posted on 2004-04-21 22:44:04
|
Kildorf
|
I don't know how feasible this would be, and I hope no one has requested this before, but...
It'd be awfully convenient to be able to access a loaded entity's frames as an image. In other words, to be able to perform Blits (etc.) directly to an entity's frames.
I suspect that the underlying architecture might not be too pleased with doing this sort of thing, though, so I'll just go on dreaming. ^_^
Posted on 2004-04-22 00:02:35
|
vecna
|
This would be possible, except, CHRs for entities are cached and pooled, so at this time, blitting to one entities "image" would result in all entities with that CHR being modified, which is probably not the desired effect.
Posted on 2004-04-22 00:16:07
|
RageCage
|
you can probably emulate that effect killdorf.
if you blit an entity frame to a seperate image and modify it and then blit it over the entity on the map, it'd work.
Posted on 2004-04-22 01:13:07
|
