Screen buffer

[G_yoshi]

This was something that came to me while at work today. Basically, there would be a new command with parameters that does a screen capture like alt+2 but it keeps it in memory. Some of the parameters that could be used with it could capture just the level, the level with NPCs and showimgs on layers 1-3, and capturing the entire screen. The buffered image could be accessed by #p like those sent by a triggeraction.

For playerworlds that are of a modern theme this could be used in conjunction with showimg to make something of a video display for a camera security system (you'd want to do changeimgzoom with a factor less than 0.9). For other things it could be used for effects similar to the script Kaimetsu did for my Doragon Koden logo for those that have seen it. There would also, then, be the potential to somehow send the buffered image to a webpage where you could check out the game in a webcam-like view; sometimes a still picture is not enough

[adam]

Would be invaluable for some awesome screen transition effects.

I think video would be too difficult though

[G_yoshi]

Originally posted by adam
Would be invaluable for some awesome screen transition effects.

I think video would be too difficult though

Let me rephrase that: "video"

What I meant was that this feature would kind of stream the buffered screen to another place, say an inner level, where the image is displayed on something that looks like a monitor.

[-Ramirez-]

Like a portal on Quake 3? (Probably other games too.)

[G_yoshi]

Originally posted by -Ramirez-
Like a portal on Quake 3? (Probably other games too.)

Something like that.

[G_yoshi]

*pokes the thread with a stick*

[Termina_Owner]

NPC Code:

---

setarray playersx,playercount;

setarray playersy,playercount;

for (i=0;i<playercount;i++){

  playersx[i] = player[i].x;

  playersy[i] = player[i].y;

}

---

In breif: Make your own parameters for the Camera.

*cough*LAG*cough*

For webpages.... It won't be possible... Well, it IS possible, but won't be happening, unless you put a life webcam on your computer, and have your guy constantly move, and send what your webcame shows.

[R0bin]

Originally posted by Termina_Owner

NPC Code:

---

setarray playersx,playercount;

setarray playersy,playercount;

for (i=0;i<playercount;i++){

  playersx[i] = players[i].x;

  playersy[i] = players[i].y;

}

---

pits players[].x not player[].x :P

[Termina_Owner]

I didn't check it. I don't use players[].# usually... When I do, I check if I got it down right. Didn't bother now.

[G_yoshi]

Originally posted by Termina_Owner

NPC Code:

---

setarray playersx,playercount;

setarray playersy,playercount;

for (i=0;i<playercount;i++){

  playersx[i] = player[i].x;

  playersy[i] = player.y;

}

---

In breif: Make your own parameters for the Camera.

*cough*LAG*cough*

For webpages.... It won't be possible... Well, it IS possible, but won't be happening, unless you put a life webcam on your computer, and have your guy constantly move, and send what your webcame shows.

You don't seem to understand. With a particular command, Graal would take a screenshot that would be stored in memory. It could be accessed by parameters or attributes and, in the case of playerworlds with NPC Servers, the image in memory could be saved to the FTP or some location and then be opened from a webpage.

Really, all you'd need is a db NPC that randomly selects players online based upon playerindex. The NPC could 'track' the actions of the randomly selected player. Then it could be saved to the server's filespace and then access by the Graal main page much like it used to do for the player stats. It wouldn't be that hard

Using multiple showimgs and whatnot slows down older computers. This would just take a window/screen snapshot and put it in memory until something else wrote over where its stored. Buffering the screen to memory could allow for certain transition effects seen in games like Final Fantasy. It would be kept client-side unless used with a dbNPC which could possibly store it on the server itself.

To be honest, I suggested this in the first place because I wanted to do some nice screen transitions. Its kind of difficult to do that as of now. I only threw in the other things about it to make it more appealing and useful since I'm sure all of it is possible in some form or another.

This is probably what the command(s) could look like:

//Client-side command
takesnap attrib; takes a snapshot of the playing window/screen and stores it in specified attribute #P()

//Client-side/Server-side command
takesnap2 playerindex,x,y,attrib; takes a snapshot of the specified playerindex with x and y being the frame size. Stored in #P()

[MrGannondorf]

It is an intresting idea, and has potentual to be a good one, too. I think that the real problem is that images have a file size. The people with dialup would track you down and light you on fire if this were handled as you sugested.

Oh, and people still use dialup, if you had your doubts.


Anyhow, my idea to making this better, would be to make it so the snapshot isn't captured as image data, but something a little similar to vecter graphics instead (no, I don't mean actual vecters, just continue to read).

Now, I don't mean actual vectors (lest you're using polygons), but instead information only needed to recreate what is seen onscreen. For example, the level's tile data, and npc information to recreate what was onscreen... like level snapshots, but better. (I supose the vecter formats would be much like a gani's format, but with tiledata, etc).

The command would look something like this:

NPC Code:

---

screencapture p1,p2;

---

The first parameter would be the filename. The second parameter would be the layer (or layers, in the form of an array) it would capture... or a variable "all layers" or something that represents every screen layer. Other parameters could be things like the area of the level board you want to capture, rather than using the current screen area.

Now, yes that solves the filesize problem, but it sure doesn't make it useable...

this might, though...

NPC Code:

---

screenmake p1;

---

The parameter would be the filename. This command would take the said "vecter" data and make it into an image. The actual conversion would happen clientside, even if the command was run serverside... that way the image can be sent in a more compact format, and then inflated into the person's webgifs folder. There is plenty of room for more parameters, like one to inflate it on the server's space so it can be used for a webserver or something.

[G_yoshi]

Originally posted by MrGannondorf
It is an intresting idea, and has potentual to be a good one, too. I think that the real problem is that images have a file size. The people with dialup would track you down and light you on fire if this were handled as you sugested.

Oh, and people still use dialup, if you had your doubts.


Anyhow, my idea to making this better, would be to make it so the snapshot isn't captured as image data, but something a little similar to vecter graphics instead (no, I don't mean actual vecters, just continue to read).

Now, I don't mean actual vectors (lest you're using polygons), but instead information only needed to recreate what is seen onscreen. For example, the level's tile data, and npc information to recreate what was onscreen... like level snapshots, but better. (I supose the vecter formats would be much like a gani's format, but with tiledata, etc).

The command would look something like this:

NPC Code:

---

screencapture p1,p2;

---

The first parameter would be the filename. The second parameter would be the layer (or layers, in the form of an array) it would capture... or a variable "all layers" or something that represents every screen layer. Other parameters could be things like the area of the level board you want to capture, rather than using the current screen area.

Now, yes that solves the filesize problem, but it sure doesn't make it useable...

this might, though...

NPC Code:

---

screenmake p1;

---

The parameter would be the filename. This command would take the said "vecter" data and make it into an image. The actual conversion would happen clientside, even if the command was run serverside... that way the image can be sent in a more compact format, and then inflated into the person's webgifs folder. There is plenty of room for more parameters, like one to inflate it on the server's space so it can be used for a webserver or something.

My idea isn't meant to automattically save it to disk. Its to buffer it into RAM until another image is buffered. Only a saving function should be used for online via the NPC server so that a webpage could load it. Obviously, it could be buffered into memory and use Graal's image color conversion that it uses for generating the map image to reduce the actual amount of data its using. This is also why I had a second command idea that allows you to specify an actual window area. That way you don't have someone dumping in an NPC that takes a 1600x1200 every 0.1 seconds and sending it out (I'd put a limit of 640x480 on it anyway).

I want it to be captured like a regular alt+2 screenshot but kept in memory rather than put on disk.

This feature would have to be used clientside since dbNPCs are not made to deal with graphics. Just allowing something like savelog to save the image to the playerworld's filespace.

And to inform, I am cursed with dialup I don't need any silly lectures.

[Admins]

It is planned to be integrated into v3.1 sometime, also a command to send a buffer to the server (would be limited in file size / how often you can send it though)

[G_yoshi]

Originally posted by Stefan
It is planned to be integrated into v3.1 sometime, also a command to send a buffer to the server (would be limited in file size / how often you can send it though)

I love you