| |
V3 function request - version 2 Displaying 1-20 of 25 total.
12
next
Overkill
|
I know that the old V3 function request thread made way for a lot of missing features, so I've made a second thread.
Here are some things I would like to see in. Yes, I admit some of it is a little overambitious, but hey, it's the thought that counts.
- void DestroyEntity(int ent) - Completely removes the entity from the map. Of course, I guess you could just go entity.visible[ent]=0; but I'm sure that invisible entities are still processed.
- int AddLayer(string layername) - Add layers to a map at runtime.
- Map 'wrapping', for such things as world maps.
- Have GetInt/SetInt/GetString/etc work on structs.
- int SocketConnectPort(string hostname, int port)
- void SocketSendRaw(int socket, string raw)
- string SocketGetRaw(int socket)
- Fix an annoying problem that makes Windows 98 do this when you set 'automax 0':
I tire of having to manually resize the window all the time.
- string GetZoneFunction(int x, int y) - Get the function name of a zone.
- string entity.callfunc[entity]; - Allows EntitySpawn'd ents to have events.
- int entity.collide[entity]; - Allow an entity's event to be triggered when the player 'touches' them (1), or is adjacent to them (2).
- int GetObsPixelRect(int x, int y, int x2, int y2) - Returns 1 if part of the entity's hotspot is in an obstruction. This sure would be useful to have embedded in the engine, because it's fairly slow to do such detection in VC.
- Multi-layer obstructions. This would prevent people from having to make their own movement engine and entity control system. ...Probably not that feasable.
- Allow custom compile images by setting it in 'v3.cfg'.
- void HueSwap(int hue_in, hue_out, int tolerance, int src, int dest) - replace the hue of a certain color with another with a hue tolerance range and then output the image.
- void ColorSwap(int color_in, color_out, int tolerance, int src, int dest) - replace a color with another with an RGB tolerance range and then output the image.
- int GetH(int c) - returns the hue HSV value for a color.
- int GetS(int c) - returns the saturation HSV value for a color.
- int GetV(int c) - returns the brightness HSV value for a color.
- int HSV(int h, int s, int v) - Converts HSV into a color, in a similar manner to the builtin RGB() function.
I know I have more requests than that, but that's all I can come up with for now. Anyone else have some ideas of features that v3 should add?
Posted on 2005-01-23 11:17:10 (last edited on 2005-01-23 12:41:10)
|
Technetium
|
I definitely second the one for making maps wrap. Of course, that would also require a new maped (unless it was something that you could set in the map's vc code). I'd suggest:
int curmap.wrapx
int curmap.wrapy
Both would be read/write, and they would be set at 1/0.
Some other map variables I want to see:
int curmap.numlayers
int curmap.layer[]
The last would be defined in length by curmap.numlayers. I would only include map layers. The index would reference layers in the order defined in the renderstring. So if you have a renderstring that starts off '4261', then curmap.layer[0]=4, curmap.layer[2]=6, etc.
I would also like to see rendermap(int x, int y, int destimage) changed to:
rendermap(int x1, int y1, int x2, int y2, int dx, int dy, int destimage)
That way you could specify to render just a part of the map.
To go with it, and to be used the with first map variables I suggested, there would also be:
renderlayer(int x1, int y1, int x2, int y2, int dx, int dy, int layer, int destimage)
...which would work the same way except only draw the specified layer layer.
The presence of these variables and functions would do much to facilitate the creation of a mode-7-style world-map similar to the one in FF6.
Posted on 2005-01-24 08:24:04
|
Omni
|
Technetium:
So, when you render this rectangle of map area, do you want it scaled to fit the size of the destination?
Posted on 2005-01-24 12:53:29
|
Technetium
|
Quote:Originally posted by Omni
Technetium:
So, when you render this rectangle of map area, do you want it scaled to fit the size of the destination?
No, that is something that could be done with another step in vc which wouldn't add terribly to the amount of time needed to process it. The problem with rendermap rendering the whole map is that some maps are huge, and have many layers. If I only want a small part of a large map (say, 500x500 or so for a world map), I would think there would be a measurable difference in time needed to do it the current way (render the whole thing to a huge buffer, and then grab a small piece into a 2nd buffer) vs. just rendering the part you want.
Posted on 2005-01-24 20:39:07
|
Omni
|
er...why not set the xwin and ywin and then render your desired section into a small buffer to begin with?
create 500x500 image
set xwin, ywin = x1, y1
then call RenderMap.
That should do it, right?
Posted on 2005-01-24 21:44:06
|
Beni
|
This may be lofty, but I think that everyone would benefit greatly from it.
In a .chr mak file, you should be able to declare other animations besides the 4 walking animations. You would give them your own names, like swing or jump.
Then, instead of making this complex function that requires controlling the flow of the game manually, causing difficulties with timing and placement, you would just call something like
entity.animation[BOB] = 'jump'
Posted on 2005-01-25 07:41:18
|
Gayo
|
As long as we're entertaining pipe dreams, optional tile-based movement.
Posted on 2005-01-25 14:35:31
|
Omni
|
It's possible to do tile movement in VC and make it good! We just haven't put enough effort into it yet...
Posted on 2005-01-25 16:27:49
|
Technetium
|
Quote:Originally posted by Omni
er...why not set the xwin and ywin and then render your desired section into a small buffer to begin with?
create 500x500 image
set xwin, ywin = x1, y1
then call RenderMap.
That should do it, right?
xwin and ywin don't affect which area of the map is drawn by rendermap. It's always the whole map, regardless of where the screen is. At least, it's worked that way for me.
Posted on 2005-01-25 18:59:57
|
Omni
|
Xwin and Ywin determine the starting position of map rendering. They are the position rendered in the upper left hand corner of the destination.
If RenderMap doesn't pay attention to Xwin and Ywin, well, I got it wrong. I thought it was just supposed to call Render() on an image of arbitrary choice. It should behave exactly like Render, or at least that's what I figured the idea was. If not, oops...someone messed up.
Posted on 2005-01-25 21:55:21
|
blues_zodiakos
|
Well, it is kind of handy as it is - you can rendermap, scale it, alphablit it, and voila, minimap (there are 4 commas in that sentence). I don't think it's what everyone had in mind, though. :D
I'm still looking for a way to do easy parallax layer work with scrolling. Stuff like Final Fantasy 6's floating continent are very difficult to do right now without superheavy scripting.
Posted on 2005-01-26 03:15:31
|
Omni
|
...RenderMap() sounds so stupid. And here I was fixing to base my new code around it...
Posted on 2005-01-26 07:49:14
|
Overkill
|
Argh, you people obviously don't realize that it's:
RenderMap(xwin,ywin,img); //Gives you your actual image
AND NOT:
RenderMap(0,0,img); //Will blit the top corner of the map, regardless.
Which is why your attempts with RenderMap() have failed.
Supply the camera coordinates and not the blit coordinates and it will work.
Posted on 2005-01-26 14:19:40 (last edited on 2005-01-26 14:22:17)
|
Omni
|
...Argh, you people obviously misled me.
Posted on 2005-01-26 21:49:46
|
Technetium
|
Oh yeah, a HUGE request I forgot about... How about changing map animations entirely so that they work like entity movescripts? Something like 'T234W30T14W30' would toggle between tile 234 and tile 14 with a wait of 30 timer clicks between each. This would let you have pauses of different lengths between the changes instead of having to import duplicate tiles. It would also let you have the animation sequence be of non-adjacent tiles in the tileset. It is really annoying importing images when I am intending on them being animated, because I can't just import each image at a time. Instead, I have to go through each file and import each 16x16 piece at a time. Sometimes I forget this, and unfortunately Maped has no undo for importing images into the tilesets so I have to close and restart it. Finally, this kind of system would be one that is easily changed in VC; meaning you can turn individual map animations on or off, and also change them during the game. The would be stored in variables like:
string map.animation[] // the animation string, read/write
int map.animationOn[] // toggles whether the animation is currently active or not, also read/write
Posted on 2005-01-28 20:25:45
|
blues_zodiakos
|
We do have direct read/write access to the tile array, right? It would probably be easy to make a reasonably speedy tile animation system like that in VC. It would actually be pretty cool.
Posted on 2005-01-29 03:21:28
|
Omni
|
Yup.
Posted on 2005-01-29 07:45:47
|
RageCage
|
I don't think this has been thought of yet:
drawPixelSet( pixelArray, screen );
and either a variable type that would allow
myPixelSet.x/.y/.color
or just a pixelSet[x][y].color
so then you could do your own pixel-pushing if you wanted to in an array and it would be much quicker than doing a shit load of setPixels
Posted on 2005-02-07 07:39:44
|
Omni
|
Well, while we're at it, why don't we just have the ability to embed actual C code in our VC?
void autoexec()
{
runC{
//some C code
}
Exit('Done!');
}
:)
Posted on 2005-02-07 11:35:26
|
RageCage
|
I don't think that would be very feasable and I doubt vecna wants to make an engine that could ever be potentially used for anything except what it's meant for.
although, I want to encourage verge to build on it's advanced library of functions. Such as the sprite system, netcode, DMA, and hopefully a system for fast pixel-pushing.
Posted on 2005-02-07 17:16:26
|
Displaying 1-20 of 25 total.
12
next
|
|
