Canceled My new mods/ 3 demos download in 1st post 0.5
- Thread starter ABK
- Start date
-
- Tags
- original ip
Project is halted prior to completion and will not receive further updates.
it's looking cool, keep it up ;D
Im experimenting with zoom and perspective, it gives nice 3d effect , ive seen it here before i think but i dont remember if it was with speed also affected by Z offset.
Heres the ondrawscript code which was posted by someone, i think Ilu on forums, i adjusted it, its a bit dirty , id like to adjust walking speed differently but it works:
Interesting is that i think its possible to create 200xscale smooth sprites for me and use them at 100% scale during this closeup so when character is that close to the screen he isnt that pixelated, this does not scale bboxes and velocities of attacks so... just a trick.
Heres the ondrawscript code which was posted by someone, i think Ilu on forums, i adjusted it, its a bit dirty , id like to adjust walking speed differently but it works:
Code:
void main()
{
void self = getlocalvar("self");
int z = getentityproperty(self, "z");
void sp = getentityproperty(self,"speed");
int ypos = openborvariant("ypos");
int zoom = 500 + (z - 800 ) ;
int zspeed = 0.5 + (z / 250-1600/500/2/2 ) ;
drawstring(110,380,0,"SPEED_-_" + sp/100000);
drawstring(110,410,0,"ZOOM_-_" + zoom/100000);
if(zoom < 0) {zoom = 0;}
setdrawmethod(self, 1, zoom , zoom , 0, 0, 0, -1);
changeentityproperty(self, "speed", zspeed );
}Interesting is that i think its possible to create 200xscale smooth sprites for me and use them at 100% scale during this closeup so when character is that close to the screen he isnt that pixelated, this does not scale bboxes and velocities of attacks so... just a trick.
Yes im susprised at how good it looks when also walking speed is adjusted dynamically, my sprites are bigger than usual so the bigger the 100% sprites the better it looks, i think you could make even more hires sprites to be displayed on closeup at their actual 100% scale without any pixelation at all, and scale them down when far from screen.
If bbox could be scaled like this and velocities would also be adjusted then it would be interesting, right now theres too many variables at play , i think you can resize bboxes by script but i did not look for it yet , it can work for something like adventure game ,without attacks and stuff, or maybe for platformer if we could figure out how to scale dynamically jump velocities as well.
Damon Caskey do You think its actually possible to do at the moment with available properties ? I know You had plans for it from this post :
http://www.chronocrash.com/forum/index.php?topic=4549.msg63120#msg63120
If all enemies onscreen would scale like this, it would look really great.But the downside is losing visibility of playable area for other players , in 4 playr mode you would see one player fighting enemy close to camera while covering entire playable area., im not sure if it swhat people would like, they might complain about it , maybe 2 player game would work better, but its definitely something im interested with.Its one of these things that look great but might not work that great because of obscuring the view, moderate amount would be better, not as close to camera like on my example unless you really want it.
Also i would preferably make it separate from drawmethod completely so it doesnt affect drawmethod effects.
If bbox could be scaled like this and velocities would also be adjusted then it would be interesting, right now theres too many variables at play , i think you can resize bboxes by script but i did not look for it yet , it can work for something like adventure game ,without attacks and stuff, or maybe for platformer if we could figure out how to scale dynamically jump velocities as well.
Damon Caskey do You think its actually possible to do at the moment with available properties ? I know You had plans for it from this post :
http://www.chronocrash.com/forum/index.php?topic=4549.msg63120#msg63120
If all enemies onscreen would scale like this, it would look really great.But the downside is losing visibility of playable area for other players , in 4 playr mode you would see one player fighting enemy close to camera while covering entire playable area., im not sure if it swhat people would like, they might complain about it , maybe 2 player game would work better, but its definitely something im interested with.Its one of these things that look great but might not work that great because of obscuring the view, moderate amount would be better, not as close to camera like on my example unless you really want it.
Also i would preferably make it separate from drawmethod completely so it doesnt affect drawmethod effects.
O Ilusionista
Captain 100K
bWWd yeah it was me - I have this uTunnels code since long time. Its pretty cool.
But you will have some issues, as I've found when I was doing tests with it:
- fmap won't work, since setdrawmethod takes precedence over it
- any drawmethod (those shortcuts) won't work too, because setdrawmethod by script is persistent.
- Shadows will work but, If I can rember well, mirror won't (I really can't remember).
- you would need to take care of all x velocities, not only walking (something not even SNK took care on the first Fatal Fury, you can notice it if you pay attention when you are on the back layer)
- bbox and attackboxes won't be scalled
The last one could be bypassed using weapons/alternate models, but it would be a pain to handle.
Yes, that would be better.
O Ilusionista
Captain 100K
Yes Youre right and also bindentity issues, but i think almost all of these can be solved by acquiring zoomed in value from ondrawscript, stored as globalvar so all your scripts can be planned to include the scaling factor all the time, so it should be a big deal, bboxes and velocities are problem, fmap is something i use rarely.Sure it would be nice to have it working but not having it working is a small price for that 3d effect that you could get with scaling working fully and properly.
But like i wrote before, completely new function to do this scaling would be much better, the one that would not interfere with drawmethod and would reduce velocities and bboxes by percentage of your scale .
Yes id probably use a trick to swap from hires to lowres model somewhere in the middle to get best results, i tried scaling hires image but nearest neighbour doesnt look that good , maybe if there would be bilinear scaling..
But like i wrote before, completely new function to do this scaling would be much better, the one that would not interfere with drawmethod and would reduce velocities and bboxes by percentage of your scale .
Yes id probably use a trick to swap from hires to lowres model somewhere in the middle to get best results, i tried scaling hires image but nearest neighbour doesnt look that good , maybe if there would be bilinear scaling..
O Ilusionista
Captain 100K
bilinear scaling would be awesome. When this was implemented in Mugen, it was a game changer.
There are times where one or another method are better though.
Yeah, the bind won't be a problem, just a little tedious to do.
There are times where one or another method are better though.
Yeah, the bind won't be a problem, just a little tedious to do.
bWWd said:
bWWd,
You don't have to do this. Part of my updates are a better way to access drawmethod, but it's already readable in older engines too. My binding/grapple scripts already compensate for scaling. Isn't hard at all, here's the function:
Code:
// Caskey, Damon V.
// 2018-11-19
//
// Return an adjusted offset to compensate for
// X scaling effects target may have applied.
int dc_elmers_find_scaled_offset_x(void target, int offset)
{
float scale;
// Get the offset.
offset = dc_elmers_get_offset_x();
// Is there a valid target entity?
target = dc_elmers_get_target();
if (typeof(target) == openborconstant("VT_PTR"))
{
// Get target scale. If it's a valid number,
// then divide it by max value to get a scale
// percentage.
scale = getdrawmethod(target, "scalex");
if (scale)
{
scale = scale / DC_ELMERS_DRAWMETHOD_SCALE_MAX_X;
}
// Multiply offset by scale percentage to get
// an offset that compensates for the
// target's current size.
offset *= scale;
// Round and cast result as integer.
offset = trunc(round(offset));
}
return offset;
}I doubt anyone remembers, but I actually built this feature into one of module projects back in 2008.
https://www.youtube.com/watch?v=QwVL9LUenVY
https://www.youtube.com/watch?v=4RGkZAEwEnU
After a while, I took it out except for fatalities and special situations (like O Ilusionista's sentinel boss). Not because of collision, but jump height. If you don't scale the sprites a lot while they're in the playfield, collision is fine. But jumping is always messed up. After a little research I found that not even Neo-Games fixed jump height. Play the old Fatal Fury games where you scale into the background but keep all your moves and you'll see it. The collision scales but nothing else does - once you notice it you can't ignore it. And if you DID fix jump height, you'd have an even bigger problem - in game functionality like certain jump based moves, pits, stage obstacles, and whatever else designed for a given jump height are broken. So then you have to design your whole game around it, and the math starts getting real crazy, real fast. This is probably why later Neo games ditched that feature and instead opted to scale the whole playfield (which isn't that hard to do with OpenBOR, just takes some pre-planning, but that's another subject).
Anyway, I'm looking at a scale feature for collision - no promises, it's in the "research" phase right now, but I think it could be workable. I can tell you there's just no way to allow a literal dynamic resizing of every box. That would mean the boxes each get doubled into entity/model like hitpoints. CPU and static memory use would go through the roof for everyone. So if you want to do something that crazy, you have a script option.
What I can do is add an entity level scale setting that gets applied into the collision detection routine calculations. So the actual boxes in memory don't change, but their effective size when a collision check happens does. I can do something similar as the debug mode draws them on screen. Then using script, you can change the entity level scale value the same as you would drawmethod, and collisions are good to go.
Jump and other velocities are a whole other matter. Like I said above, you can't just scale them and call it a day - you have to worry about a ton of possible side effects in your game. So for now, I'm just going to worry about collision.
O Ilusionista said:
Sorry O Ilusionista, there are no plans at all for different algorithms.
DC
Ive seen these, yeah you got it working nicely , i think if i would make any sort of holes or platforms then i would have separate height,length for background and foreground , holes ultimately dont move around, platforms too, unless you want them to.These arenot big issues, or just dont use them.
So did You managed to scale jump height dynamically? It would be great to have this sort of scaling with collissions and all.
Ive seen some 2d games using it but none of them used it nicely , that new battletoads has it but it just looks poor cause it doesnt have any effect , its too subtle to even care, and knowing how many issues scaling like this can produce i have no clue why they even bothered if its so minimal.
The best would be ultimately real 3d floor and enviroment, characters would be planes/textures and backgrounds simple 3d shapes texture mapped.
We currently are faking it with scaling and background parallax but it does work, looks like it so its ok, doesnt matter how its done.
Z value in attack/ bboxes can be tricky.
So did You managed to scale jump height dynamically? It would be great to have this sort of scaling with collissions and all.
Ive seen some 2d games using it but none of them used it nicely , that new battletoads has it but it just looks poor cause it doesnt have any effect , its too subtle to even care, and knowing how many issues scaling like this can produce i have no clue why they even bothered if its so minimal.
The best would be ultimately real 3d floor and enviroment, characters would be planes/textures and backgrounds simple 3d shapes texture mapped.
We currently are faking it with scaling and background parallax but it does work, looks like it so its ok, doesnt matter how its done.
Z value in attack/ bboxes can be tricky.
oldyz
Well-known member
bWWd said:
But you don't have to get them that close to the camera tho, just keep their scaling to certain limited areas, that way the biggest a sprite gets is it's normal size & the smallest is 40% (the furthest)
personally this scaling, along with some shifting of the sprite's doppleganger would help make the Stereoscopic effect of the sprites work perfectly, too bad that the hitboxes & boundary data wont scale tho - unless there is scripting that makes those scale too.
The only game or type of level that could really use close very camera zooming is an SNES Mario Kart type of game, a shooting gallery bonus round or some kind of Space Harrier scene, or attacks, like the turtles throwing foot soldiers towards the screen or far off in to the background.
I know what You mean but You have different vision about it, i have an idea, they have to be that close to camera.
I dont want to make it like most 2d games did it so its barely noticeable, i want close up to matter and have its own gameplay so it isnt just a trick, and close up fights would have higher res sprites.
I dont want to make it like most 2d games did it so its barely noticeable, i want close up to matter and have its own gameplay so it isnt just a trick, and close up fights would have higher res sprites.
oldyz
Well-known member
bWWd said:
i edited the previous reply with some level or game ideas.......
indeed, i can understand there is situations where you might want them really close, & i did mention before such an high resolution idea in one of the Turtle game threads, ( without scripting, you just use drawmethod to keep the sprites artificially small, but in reality they are well defined)
I don't know how taxing it could get for the engine or the systems it runs on tho...
at this very moment i can picture a re-make of the Snes jurassic park game, the one that looked like Zelda that had 1st person Doom-like corridors, those could surely use enhanced sprites &scaling.....
oldyz
Well-known member
bWWd
crossing my fingers,
I might add that to get this working would make modules look better too....
I wanted to enhance NS with "mode 7" floors, but when you see it , it looks odd, the only way it can look good is if you scale the sprites to have more congruence to the floors when it comes to beat-them ups.
to visualize the difference, see how odd the lack of zoom/scaling "feels" on neon night riders in the SNES (forward to 2 minutes) https://www.youtube.com/watch?v=1bIF5B0P3z8
to how it should work (remake) https://www.youtube.com/watch?v=5W9aXc_rg4A
now , when mode 7 comes to fighting games & platformers, there is not really a problem because most of the sprites will stay only in one "Z" an never move from there, & most enemies that zoom in, or out, don't have any "physicality" to them until they are in the right spot.
Question, do you like do you like those old -school Kings Quest games?
crossing my fingers,
I might add that to get this working would make modules look better too....
I wanted to enhance NS with "mode 7" floors, but when you see it , it looks odd, the only way it can look good is if you scale the sprites to have more congruence to the floors when it comes to beat-them ups.
to visualize the difference, see how odd the lack of zoom/scaling "feels" on neon night riders in the SNES (forward to 2 minutes) https://www.youtube.com/watch?v=1bIF5B0P3z8
to how it should work (remake) https://www.youtube.com/watch?v=5W9aXc_rg4A
now , when mode 7 comes to fighting games & platformers, there is not really a problem because most of the sprites will stay only in one "Z" an never move from there, & most enemies that zoom in, or out, don't have any "physicality" to them until they are in the right spot.
Question, do you like do you like those old -school Kings Quest games?