Moving planes efficiently in OpenGL

Jun 25, 2007 at 1:10pm

Moving planes efficiently in OpenGL

You will also need the following.

Many thanks

Andy

max v2;
#N vpatcher 1149 109 2425 1089;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N in 5;
#P newobj 696 329 25 196617 in 5;
#P newex 696 356 82 196617 t b b b;
#P newex 768 380 27 196617 0;
#P newex 732 380 27 196617 -2.;
#P newex 696 380 27 196617 -2.;
#N in 4;
#P newobj 639 329 25 196617 in 4;
#N in 3;
#P newobj 603 329 25 196617 in 3;
#N in 2;
#P newobj 395 329 25 196617 in 2;
#P newex 395 356 84 196617 t b b b;
#P newex 469 380 27 196617 0;
#P newex 432 380 27 196617 0.2;
#P newex 395 380 36 196617 -0.16;
#P flonum 469 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 432 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 395 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 358 452 122 196617 pak scale 0. 0. 0.;
#P flonum 768 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 732 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 696 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 660 452 118 196617 pak position 0. 0. 0.;
#P newex 320 491 144 196617 jit.gl.videoplane ken @layer 1;
#N in 7;
#P newobj 858 329 25 196617 in 7;
#N in 6;
#P newobj 822 329 25 196617 in 6;
#N in 1;
#P newobj 320 329 25 196617 in 1;
#P connect 0 0 3 0;
#P fasten 4 0 3 0 665 480 325 480;
#P fasten 8 0 3 0 363 480 325 480;
#P connect 16 0 15 0;
#P connect 15 0 12 0;
#P connect 12 0 9 0;
#P fasten 17 0 9 0 608 411 400 411;
#P connect 9 0 8 1;
#P fasten 15 1 13 0 437 376 437 376;
#P connect 13 0 10 0;
#P fasten 18 0 10 0 644 411 437 411;
#P fasten 10 0 8 2 437 446 437 446;
#P fasten 15 2 14 0 474 376 474 376;
#P connect 14 0 11 0;
#P fasten 11 0 8 3 474 446 474 446;
#P connect 23 0 22 0;
#P connect 22 0 19 0;
#P fasten 1 0 5 0 827 407 701 407;
#P connect 19 0 5 0;
#P connect 5 0 4 1;
#P connect 22 1 20 0;
#P fasten 2 0 6 0 863 407 737 407;
#P connect 20 0 6 0;
#P fasten 6 0 4 2 737 447 737 447;
#P connect 22 2 21 0;
#P connect 21 0 7 0;
#P connect 7 0 4 3;
#P pop;

#32609
Jun 25, 2007 at 2:47pm

I get 60 fps under all conditions with your patch. You may want to
consider using Javascript or something similar to manage all of this
because if you change on of those subpatches, you’re going to end up
doing 16 times the work. In a script, it’s one change and you’re
done. Either that or try to move as much into the poly~ as possible.
As far as efficiency goes, from what I can tell, each
jit.gl.videoplane instance has the same properties for drawing. You
can greatly improve drawing speed by setting up OpenGL once and
drawing 16 times with the drawraw method as opposed to always
resetting the OpenGL state machine on each draw as is done with the
standard jit.gl.* way of drawing. you can make this happen by using
jit.gl.sketch in combination with the videoplane objects.

wes

On 6/25/07, Andy Brennan wrote:
>
> You will also need the following.
>
> Many thanks
>
> Andy
>
> max v2;
> #N vpatcher 1149 109 2425 1089;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #N in 5;
> #P newobj 696 329 25 196617 in 5;
> #P newex 696 356 82 196617 t b b b;
> #P newex 768 380 27 196617 0;
> #P newex 732 380 27 196617 -2.;
> #P newex 696 380 27 196617 -2.;
> #N in 4;
> #P newobj 639 329 25 196617 in 4;
> #N in 3;
> #P newobj 603 329 25 196617 in 3;
> #N in 2;
> #P newobj 395 329 25 196617 in 2;
> #P newex 395 356 84 196617 t b b b;
> #P newex 469 380 27 196617 0;
> #P newex 432 380 27 196617 0.2;
> #P newex 395 380 36 196617 -0.16;
> #P flonum 469 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 432 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 395 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 358 452 122 196617 pak scale 0. 0. 0.;
> #P flonum 768 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 732 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 696 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 660 452 118 196617 pak position 0. 0. 0.;
> #P newex 320 491 144 196617 jit.gl.videoplane ken @layer 1;
> #N in 7;
> #P newobj 858 329 25 196617 in 7;
> #N in 6;
> #P newobj 822 329 25 196617 in 6;
> #N in 1;
> #P newobj 320 329 25 196617 in 1;
> #P connect 0 0 3 0;
> #P fasten 4 0 3 0 665 480 325 480;
> #P fasten 8 0 3 0 363 480 325 480;
> #P connect 16 0 15 0;
> #P connect 15 0 12 0;
> #P connect 12 0 9 0;
> #P fasten 17 0 9 0 608 411 400 411;
> #P connect 9 0 8 1;
> #P fasten 15 1 13 0 437 376 437 376;
> #P connect 13 0 10 0;
> #P fasten 18 0 10 0 644 411 437 411;
> #P fasten 10 0 8 2 437 446 437 446;
> #P fasten 15 2 14 0 474 376 474 376;
> #P connect 14 0 11 0;
> #P fasten 11 0 8 3 474 446 474 446;
> #P connect 23 0 22 0;
> #P connect 22 0 19 0;
> #P fasten 1 0 5 0 827 407 701 407;
> #P connect 19 0 5 0;
> #P connect 5 0 4 1;
> #P connect 22 1 20 0;
> #P fasten 2 0 6 0 863 407 737 407;
> #P connect 20 0 6 0;
> #P fasten 6 0 4 2 737 447 737 447;
> #P connect 22 2 21 0;
> #P connect 21 0 7 0;
> #P connect 7 0 4 3;
> #P pop;
>
>

#107655
Jun 25, 2007 at 4:47pm

I’m not sure in which way to use sketch and videoplane in combination, nor how to use drawraw. Are there any examples/tutorials/documentation that outline this use? I’ve had a look but can’t see anything specific.

Cheers

Andy

#107656
Jun 25, 2007 at 6:59pm

Here’s a simple example. As you can see things get complicated fast.,
but this is what you have to do if you want to maximize efficiency. I
would recommend using one of the scriping languages for managing this
kind of thing.

#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P message 79 165 301 196617 reset , glpushmatrix , gltranslate
-0.55 0 0 , glscale 0.5 0.5 0.5 , drawobject vplane 1 , glpopmatrix
, glpushmatrix , gltranslate 0.55 0 0 , glscale 0.5 0.5 0.5 ,
drawobject vplane 1 , glpopmatrix;
#P window linecount 1;
#P newex 79 239 233 196617 jit.gl.videoplane test @name vplane @automatic 0;
#P newex 79 209 85 196617 jit.gl.sketch test;
#P message 152 67 34 196617 reset;
#P newex 152 87 186 196617 jit.gl.handle test @inherit_transform 1;
#P newex 17 87 48 196617 r render;
#P toggle 132 58 15 0;
#N vpatcher 53 128 279 297;
#P inlet 106 30 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 43 95 47 196617 gate 1 1;
#P newex 42 116 41 196617 s draw;
#P window linecount 1;
#P newex 17 52 58 196617 t b b erase;
#P inlet 17 32 15 0;
#P outlet 17 83 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P fasten 2 2 0 0 70 75 22 75;
#P connect 4 0 3 0;
#P fasten 5 0 4 0 111 88 48 88;
#P fasten 2 1 4 1 46 83 85 83;
#P lcolor 15;
#P pop;
#P newobj 70 87 42 196617 p Draw;
#P toggle 208 26 15 0;
#P message 208 46 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 225 26 33 196617 p Esc;
#P newex 208 64 151 196617 jit.window test @depthbuffer 1;
#P toggle 70 39 15 0;
#P newex 70 58 57 196617 qmetro 30;
#P newex 70 114 187 196617 jit.gl.render test @erase_color 0 0 0 1;
#P connect 14 0 12 0;
#P connect 5 0 3 0;
#P connect 6 0 5 0;
#P connect 4 0 6 0;
#P connect 11 0 10 0;
#P fasten 8 0 7 1 137 80 107 80;
#P fasten 9 0 0 0 22 109 75 109;
#P connect 7 0 0 0;
#P fasten 10 0 0 0 157 109 75 109;
#P connect 1 0 7 0;
#P connect 2 0 1 0;
#P window clipboard copycount 15;

#107657
Jun 25, 2007 at 7:27pm

Thanks for that you have been a great help.

I think my main problem in this area is that I do not have a particularly in depth red book knowledge – as I do not understand what aspects of the example patch make it more efficient. I have looked through it before but being a novice at this sort of thing means I don’t absorb most of it.

Andy

#107658
Jun 25, 2007 at 7:38pm

Essentially, when a jitter object draws itself, it resets the entire
opengl state. When it does drawraw, it doesn’t do any of this.
Resetting opengl state frequently especially when there is no reason
to (i.e. when drawing lots of the same thing) can be a real
performance bottleneck. Have a look at jit.gl.multiple and try
messing with the targetmode attribute in the help patch. I have a
good graphics card so the difference is only 5fps, but on a lesser
machine or with more objects, the difference would be quite a bit
larger.

wes

On 6/25/07, Andy Brennan wrote:
>
> Thanks for that you have been a great help.
>
> I think my main problem in this area is that I do not have a particularly in depth red book knowledge – as I do not understand what aspects of the example patch make it more efficient. I have looked through it before but being a novice at this sort of thing means I don’t absorb most of it.
>
> Andy
>
>

#107659
Jun 25, 2007 at 7:55pm

Interestingly changing the target mode makes absolutely no difference on my machine. The fps fluctuates between 43 and 44 in both states – with default performance settings. The difference between the two does not seem to alter if I change performance settings – the fps changes but again has a 1-2 fps fluctuation in both states. Could this suggest that my graphics card can’t handle the task?

My graphics card is an ATI Radeon 9600.

Andy

#107660
Jun 25, 2007 at 8:18pm

Does the render image change at all?
wes

On 6/25/07, Andy Brennan wrote:
>
> Interestingly changing the target mode makes absolutely no difference on my machine. The fps fluctuates between 43 and 44 in both states – with default performance settings. The difference between the two does not seem to alter if I change performance settings – the fps changes but again has a 1-2 fps fluctuation in both states. Could this suggest that my graphics card can’t handle the task?
>
> My graphics card is an ATI Radeon 9600.
>
> Andy
>
>

#107661
Jun 25, 2007 at 8:23pm

Quote: wesley.hoke@gmail.com wrote on Mon, 25 June 2007 14:18
—————————————————-
> Does the render image change at all?
> wes

The image does change.

Unchecked the objects seem to be varying shades of grey.

Checked the objects are all the same colour.

Just no change in fps.

Cheers Andy

#107662
Jun 25, 2007 at 8:49pm

Ah,
Sorry, I was mistaken in how jit.gl.multiple works internally. Here’s
a patch using sketch that actually shows what I was trying to explain.
With uzi set to 100, I see a 15fps difference between draw and
drawraw.

wes

#P window setfont “Sans Serif” 9.;
#P number 250 232 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 168 319 102 196617 glunbindtexture mov;
#P window linecount 2;
#P message 380 318 236 196617 glenable blend , glblendfunc 6 1 ,
gldisable depth_test , glcolor 1 0 0 0.01 , glbindtexture mov;
#P window linecount 1;
#P newex 154 249 40 196617 t b b b;
#P newex 327 226 146 196617 jit.gl.texture test @name mov;
#B color 5;
#P newex 23 218 27 196617 + 1;
#P toggle 23 196 15 0;
#P newex 272 298 44 196617 uzi 100;
#P message 272 319 102 196617 drawobject vplane 1;
#P newex 53 251 47 196617 gate 2 1;
#P user jit.fpsgui 135 193 60 196617 0;
#P newex 53 275 44 196617 uzi 100;
#P message 53 296 102 196617 drawobject vplane 0;
#P newex 67 223 49 196617 t b reset;
#P newex 67 199 41 196617 r draw;
#P flonum 528 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 528 178 42 196617 rate $1;
#P message 417 157 65 196617 read oh.mov;
#P message 462 178 27 196617 stop;
#P message 428 178 31 196617 start;
#P flonum 371 157 35 9 0.5 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 329 157 15 0;
#P newex 329 177 52 196617 metro 30;
#P message 492 178 31 196617 clear;
#P newex 329 205 103 196617 jit.qt.movie 320 240;
#B color 5;
#P newex 53 362 85 196617 jit.gl.sketch test;
#P window linecount 2;
#P newex 329 247 285 196617 jit.gl.videoplane test @name vplane
@automatic 0 @color 1 0 0 0.01 @depth_enable 0 @blend_enable 1
@blend_mode 6 1;
#P window linecount 1;
#P message 153 94 34 196617 reset;
#P newex 153 114 186 196617 jit.gl.handle test @inherit_transform 1;
#P newex 18 114 48 196617 r render;
#P toggle 133 85 15 0;
#N vpatcher 53 128 279 297;
#P inlet 106 30 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 43 95 47 196617 gate 1 1;
#P newex 42 116 41 196617 s draw;
#P window linecount 1;
#P newex 17 52 58 196617 t b b erase;
#P inlet 17 32 15 0;
#P outlet 17 83 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P fasten 2 2 0 0 70 75 22 75;
#P connect 4 0 3 0;
#P fasten 5 0 4 0 111 88 48 88;
#P fasten 2 1 4 1 46 83 85 83;
#P lcolor 15;
#P pop;
#P newobj 71 114 42 196617 p Draw;
#P toggle 209 53 15 0;
#P message 209 73 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 226 53 33 196617 p Esc;
#P newex 209 91 151 196617 jit.window test @depthbuffer 1;
#P toggle 71 66 15 0;
#P newex 71 85 51 196617 qmetro 3;
#P newex 71 141 187 196617 jit.gl.render test @erase_color 0 0 0 1;
#P comment 220 210 100 196617 # of instances;
#P connect 39 0 28 1;
#P connect 39 0 32 1;
#P connect 33 0 34 0;
#P connect 34 0 30 0;
#P connect 30 0 28 0;
#P connect 28 0 27 0;
#P connect 38 0 14 0;
#P connect 37 0 14 0;
#P connect 31 0 14 0;
#P connect 27 0 14 0;
#P connect 26 1 14 0;
#P connect 25 0 26 0;
#P connect 3 0 2 0;
#P connect 2 0 8 0;
#P fasten 10 0 1 0 23 136 76 136;
#P connect 8 0 1 0;
#P fasten 11 0 1 0 158 136 76 136;
#P connect 26 0 30 1;
#P fasten 9 0 8 1 138 107 108 107;
#P connect 25 0 29 0;
#P connect 12 0 11 0;
#P connect 30 1 36 0;
#P connect 36 0 38 0;
#P connect 5 0 7 0;
#P connect 7 0 6 0;
#P connect 6 0 4 0;
#P connect 36 1 32 0;
#P connect 32 0 31 0;
#P connect 15 0 35 0;
#P connect 18 0 17 0;
#P fasten 23 0 15 0 533 199 334 199;
#P fasten 22 0 15 0 422 199 334 199;
#P fasten 21 0 15 0 467 199 334 199;
#P fasten 20 0 15 0 433 199 334 199;
#P fasten 16 0 15 0 497 199 334 199;
#P fasten 17 0 15 0 334 202 334 202;
#P connect 35 0 13 0;
#P connect 19 0 17 1;
#P connect 36 2 37 0;
#P connect 24 0 23 0;
#P window clipboard copycount 40;

#107663
Jun 25, 2007 at 9:27pm

Yes that does make an improvement of around 6 fps on my system. Can I ask what resources you used to learn his stuff as I think I really should look into it myself and get my head around it. My main problem is that my experience lies more with interactive audio systems design rather than actual in-depth graphics programming, so a lot of the principles that lend to a more successful and efficient application are alien to me.

Cheers for all your help.

Andy

#107664
Jun 25, 2007 at 10:39pm

> Yes that does make an improvement of around 6 fps on my system. Can I ask what resources you used to learn his stuff as I think I really should look into it myself and get my head around it.

- Reading the specs of OpenGL docs like the Redbook and the OpenGL 2.1
PDF ( http://www.opengl.org/registry/doc/glspec21.20061201.pdf ) Also
the man pages for the different functions
- Looking at other people’s code like NeHe ( http://nehe.gamedev.net/ )
- Lot’s of practice and trying things out
- Subscribing to various mailing lists like the Apple OpenGL list to
catch tips here and there

wes

#107665
Jun 26, 2007 at 12:57am

Thats great. Thanks a lot for your help. Its been really appreciated.

Andy

#107666
Jul 2, 2007 at 5:51pm

and may i suggest a few things that didn’t come up in this discussion.
1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you’re running. better to use your main metro to manually ramp and set scale+positions only once for each frame.
2. remove all those number boxes. with 16 poly voices you’ve got 100+ updating at 20ms. again those line objects. all gui objects eat framerate.
3. avoid to [pak] scale and positions if possible. you’ll get x3 messages for each change. pack is better for collecting and then bang right before you output a frame.

_f

#107667
Jul 3, 2007 at 10:19am

Quote: f wrote on Mon, 02 July 2007 11:51
—————————————————-
> and may i suggest a few things that didn’t come up in this discussion.
> 1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you’re running. better to use your main metro to manually ramp and set scale+positions only once for each frame.
> 2. remove all those number boxes. with 16 poly voices you’ve got 100+ updating at 20ms. again those line objects. all gui objects eat framerate.
> 3. avoid to [pak] scale and positions if possible. you’ll get x3 messages for each change. pack is better for collecting and then bang right before you output a frame.
>
> _f
—————————————————-

They all seem like good suggestions. I had often wondered if the inclusion of number boxes had any efect. I always kept them in as a way to monitor the system. I’ll give them a go.

Cheers

Andy

#107668
Jul 5, 2007 at 1:27pm

Sorry to keep this post going but I’m not having much luck in sorting out my problem.

Maybe there is better way of doing what I require that I don’t know? – i.e. not moving planes in OpenGL.

(I have tried all suggestions and can’t seem to get any significant improvements)

Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential – i.e the amount of time taken from object start to object end position.

I’m going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.

Does anybody have any thoughts?

Cheers

Andy

#107669
Jul 5, 2007 at 2:32pm

Well, with 16 identical things, graphics programming is probably not
the easiest way to go. I would suggest at the very least using
javascript or if you don’t mind diving into something a bit more
involved using jit.gl.lua. The idea would be to model the behavior
you want once and use it 16 times with timing patterns affecting the
parameters of the individual objects.

wes

On 7/5/07, Andy Brennan wrote:
>
> Sorry to keep this post going but I’m not having much luck in sorting out my problem.
>
> Maybe there is better way of doing what I require that I don’t know? – i.e. not moving planes in OpenGL.
>
> (I have tried all suggestions and can’t seem to get any significant improvements)
>
> Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential – i.e the amount of time taken from object start to object end position.
>
> I’m going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.
>
> Does anybody have any thoughts?
>
> Cheers
>
> Andy
>
>
>

#107670
Jul 5, 2007 at 2:32pm

Sorry that should say “graphical programming” not “graphics programing”

wes

On 7/5/07, Wesley Smith wrote:
> Well, with 16 identical things, graphics programming is probably not
> the easiest way to go. I would suggest at the very least using
> javascript or if you don’t mind diving into something a bit more
> involved using jit.gl.lua. The idea would be to model the behavior
> you want once and use it 16 times with timing patterns affecting the
> parameters of the individual objects.
>
> wes
>
> On 7/5/07, Andy Brennan wrote:
> >
> > Sorry to keep this post going but I’m not having much luck in sorting out my problem.
> >
> > Maybe there is better way of doing what I require that I don’t know? – i.e. not moving planes in OpenGL.
> >
> > (I have tried all suggestions and can’t seem to get any significant improvements)
> >
> > Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential – i.e the amount of time taken from object start to object end position.
> >
> > I’m going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.
> >
> > Does anybody have any thoughts?
> >
> > Cheers
> >
> > Andy
> >
> >
> >
>

#107671
Jul 6, 2007 at 10:23am

There are three methods that jump to mind here which don’t involve using any of the scripting languages.

first, as Wesley suggests use sketch. Then use the cmd_replace message to alter your glscale and gltranslate commands;

second, videoplane can run multiple planes using just the one videoplane object – set up the values for each plane and bang them in turn;

and third, you could use poly~. There are a number of ways you could set this up, depending on your circumstances, but you could consider putting an interface to common values inside the poly~ which would affect each of your 16 planes, with the main gl object outside (so you’re using only one instance of it).

pelado

#107672
Jul 6, 2007 at 10:50am

I am currently using poly~ to create and control 16 copies of the plane. This keeps things tidier but I don’t see any increase in efficiency.

Using 1 x videoplane with 16 controls – would this be any more efficient than having 16 individual planes? I imagine so to a degree. I’ll give it a go.

Sketch I have little experience with so that could be a possible area of investigation.

I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I’m hopefully going on a javascript workshop soon which will be enlightening.

My main thoughts around this subject are ones of bewilderment. I can’t believe how awkward it is to efficiently move what are effectively 16 sprites around a screen (or is it that I just don’t know what I’m doing – I guess not). I have a little experience with “sketch” languages such as “Processing” where doing the sort of thing I am trying to do would be easy – the only downfall is that it doesn’t offer a lot of the other things I require my app to do.

Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.

Thanks a lot

Andy

#107673
Jul 6, 2007 at 11:54am

It’s more efficient if you use the drawraw method of videoplane
instead of the draw method. Otherwise it will only be marginally more
efficient instead of significantly. You’ll probably want to use
jit.gl.sketch in conjunction with jit.gl.videoplane for this.

wes

On 7/6/07, Andy Brennan wrote:
>
> I am currently using poly~ to create and control 16 copies of the plane. This keeps things tidier but I don’t see any increase in efficiency.
>
> Using 1 x videoplane with 16 controls – would this be any more efficient than having 16 individual planes? I imagine so to a degree. I’ll give it a go.
>
> Sketch I have little experience with so that could be a possible area of investigation.
>
> I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I’m hopefully going on a javascript workshop soon which will be enlightening.
>
> My main thoughts around this subject are ones of bewilderment. I can’t believe how awkward it is to efficiently move what are effectively 16 sprites around a screen (or is it that I just don’t know what I’m doing – I guess not). I have a little experience with “sketch” languages such as “Processing” where doing the sort of thing I am trying to do would be easy – the only downfall is that it doesn’t offer a lot of the other things I require my app to do.
>
> Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.
>
> Thanks a lot
>
> Andy
>

#107674
Jul 6, 2007 at 4:31pm

plus, you could lower the dimensions of jit.gl.videoplane, it
defaults to 20×20 vertices, but 2×2 should be enough:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 126 217 14 196617 2;
#P message 99 218 20 196617 20;
#P message 99 242 56 196617 dim $1 $1;
#P newex 195 145 44 196617 uzi 100;
#P user jit.fpsgui 33 223 60 196617 0;
#N vpatcher 20 74 620 474;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 50 50 58 196617 t b b erase;
#P inlet 50 30 15 0;
#P outlet 99 107 15 0;
#P outlet 50 107 15 0;
#P connect 2 0 3 0;
#P connect 3 2 0 0;
#P connect 3 0 0 0;
#P connect 3 1 1 0;
#P pop;
#P newobj 33 105 40 196617 p tbe;
#P newex 33 144 82 196617 jit.gl.render vpl;
#P newex 36 337 116 196617 jit.window vpl @sync 0;
#P toggle 33 53 15 0;
#P newex 33 74 51 196617 qmetro 1;
#P newex 195 283 163 196617 jit.gl.videoplane vpl @automatic 0;
#P user panel 24 208 149 60;
#X brgb 168 186 229;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 8 0 1 0;
#P connect 9 0 1 0;
#P connect 6 1 8 0;
#P connect 11 0 9 0;
#P connect 10 0 9 0;
#P connect 3 0 2 0;
#P connect 2 0 6 0;
#P connect 5 0 7 0;
#P connect 6 0 5 0;
#P window clipboard copycount 12;

#107675

You must be logged in to reply to this topic.