View Full Version : Can GPRM's create interactivity and choice?
JoeT123
13th October 2005, 00:08
Hello,
I have a project that's previously been done in multimedia authoring applications but would like to move it to dvd if possible.
Here's what I need.
A dvd with 12 unique areas for the user to visit. I need to let the user set the order they watch them in each time they start the dvd.
Aka one day they may watch 1 to 10. Then the next day watch 3, 4, 8, 10.
Basically per view changeability.
Is this even possible with dvd's GPRM's? Or should I stick to an authoring application like Macromedia Director? (I'm hoping it's doable with dvd since that'd broaden availability of where it could be viewed)
If it is possible which software out there can do it? The only one I've heard much talk about for variable control is Scenarist. If it's the tool then the cost is justified.
Thanks,
Joe.
srfscenar
13th October 2005, 06:58
I can only tell you one thing. It CAN be done and Scenarist IS the tool for it. The only thing i dont know is how to do it :)
It is Advanced GPRM use. If u manage to do that u could do almost anything.
JoeT123
18th October 2005, 17:46
Ok then. I have a starting point. Now's the time to look at Scenarist. I was worried that it may be too complex for Scenarist to handle.
But if it's possible it's worth the head banging against the wall that will occur.
A quick addendum to this is that I talked to Tech support at Sonic and they were 99% sure it was doable. Just not easy. They are going to call me back with that last 1%'s yay or nay.
Cheesus
19th October 2005, 02:18
Hi JoeT123
I've never done anything like this before but thought it was a good opportunity to see if I was capable of writing something more interactive than I'd done before. It took me a couple of hours to get it to work, so it is possible and a good work out for the grey matter.
I think it nicely demonstrates how powerful a tool Scenarist is too.
I'm not sure if you want to experiment with Scenarist and get to the bottom of this yourself so I haven't posted how I did it. If you need help I'm more than happy to tell you how I did it though. There's probably a lot of different ways to do it and probably code wise, more effecient ways. I just used four areas to select instead of 12 because I couldn't be bothered with the amount of repetitive code you had to write for that. I also assumed there was a maximum of four titles to play when selecting i.e. the user couldn't have selected every title once and then selected another again to make a total of 5 titles to play etc. Lastly I put in a reset button and also reset when the user menu'd out of a sequence already in progress. These were only personal preferences how I'd like it to work though.
Taelon
19th October 2005, 04:36
JoeT, Buy or Rent Peter Gabriel's Play (http://imdb.com/title/tt0435717) they've done exactly what you're talking about so that you can view the videos in any order you desire. It's not really all that complicated and could likely be customized using PgcEdit or similar to suit your specific situation.
Corion
19th October 2005, 19:34
Cheesus, I'd be really interested to hear what you did. I've been looking into this myself recently and have been able to program (or rather, think of) a system that would let you cherry pick up to 15 titles but I can't define the order of play.
For the benefit of the OP, this is my plan...
Let's say, like in your example there are 4 titles and a main menu with 4 buttons. What I thought of, was to have 16 menus each identical except for some form of highlight (part of the background) in each button to show that it had been selected for play, oh and of course a "Begin" button. You'd need to show every possible combination hence (4x4=) 16.
When a button was activated I would add a vaule to a GPRM register and link to the approriate menu. For button 1, add 1; button 2, add 2; button 3 add 4; and button 4 , add 8 and so on. This would return a unique value for each combination. Naturally you would be able to deslect a button by subtracting from the GPRM register.
From the returned value(s) you could work out which menu you should be in and which titles to play once the user hits "begin" or whatever.
So how would I define the order of play? I thought about using the DVD player's temporary memory to form a stack but I'm certain Scenarist won't allow that level of access.
mpucoder
19th October 2005, 20:50
You'd need to show every possible combination hence (4x4=) 16.
The possible combinations of 4 things taken one at a time is 4! (4x3x2x1 = 24).
And this quickly gets out of hand as you add titles.
The way it is done is to build a playlist in the GPRM's, using some of them as a register file. You are still limited, as there are only 16 registers, so "packing" (storing more than one number per register by dividing the bits into fields) is required for larger playlists. Each register has 16 bits, so for a list of up to 4 titles out of 4 could be done in a single register. This is basic computer programming (and not unfamiliar to microcontroller programmers working with stingy amounts of RAM). I think I'll work up an example and put it on my site.
DaRat
19th October 2005, 22:32
The possible combinations of 4 things taken one at a time is 4! (4x3x2x1 = 24).
That's not really true if you take into account that a user can go with a partial play list too. In that case the possible combinations for 4 programs are 64 (and 1302061344 for 12, pretty insane), tough I might be wrong on the math side. :D Well, all I'm saying is displaying the order of the programs over 5 programs (325 possibilities) is really out of the question.
Cheesus
20th October 2005, 00:05
I don't have any computer programming experience, although I think I'll give it a go in the near future, so my way isn't very mathmatical. I did think about trying to work out how many possibilities there were and how you could store this information. I thought that would be possible but didn't know how to do it. However, I couldn't get my head around how you would implement a script to actually direct one title to the next, as surely you would need some coding in the post commands of the titles, especially when you start getting into large amounts of titles. The exampe of JoeT was 12 which I didn't need to calculate to know that's a huge amount of possibilities. I suppose you could use dummies in some way but I still couldn't see it. So I'd be really interested to see how Muxman would go about it.
My way, you need one GPRM per title, so Corion you're not going to be left with much in the way of GPRM's left over for any extra coding. By splitting the GPRM's up, like Muxman suggested, you could get a lot of GPRM's back. Using my way you can't subtract selections either but I just used a reset button to get around this. The way I've done it works but it's not really capable of being very adaptive.
The button links for selecting a title goto a dummy menu which sets a GPRM value based on the button. Make this easy by assigning button 1 to goto title 1.
if ( GPRM1 != 0 ) GoTo 4
Mov GPRM1, SPRM8
LinkPGCN (back to menu)
if ( GPRM2 != 0 ) GoTo 7
Mov GPRM2, SPRM8
LinkPGCN (back to menu)
Etc.
When the user has finished selecting (and as I said earlier I limited the amount of choices to the amount of titles there are) they press a start button. This links to another dummy menu which acts as a kind of navigator which redirects onto more dummy menus (one for each GPRM or title that you have in your project). These last dummy menus finally link to a title. After the title has played the post command directs back to the navigator dummy menu which again redirects onto the next GPRM etc. This whole process repeats until the play list has finished. Hope my explanation isn't too confusing.
So for my example, I used four titles and therefore four GPRM's.
Script for navigator menu is
if (GPRM1!=0) LinkPGCN x (dummy menu for GPRM1)
if (GPRM2!=0) LinkPGCN x (dummy menu for GPRM2)
if (GPRM3!=0) LinkPGCN x (dummy menu for GPRM3)
if (GPRM4!=0) LinkPGCN x (dummy menu for GPRM4)
if (GPRM4=0) LinkPGCN x (main menu)
Script for dummy menu GPRM1
1: Mov GPRM1, GPRM5
2: Mov GPRM1, 0
3: if (GPRM5 ==1024) GoTo 7
4: if (GPRM5 ==2048) GoTo 8
5: if (GPRM5 ==3072) GoTo 9
6: if (GPRM5 ==4096) GoTo 10
7: JumpVTS_TT 1
8: JumpVTS_TT 2
9: JumpVTS_TT 3
10: JumpVTS_TT 4
Just change the script appropriately for any other GPRM dummy menu.
In your precommand for all titles change GPRM5 back to 0 and in post command link back to navigator dummy menu.
I've just realised I use another GPRM so Corion you'd be left with no GPRM's :(
I'm sure this could be refined or there are more efficient ways of doing it.
Dimad
20th October 2005, 17:37
Each register has 16 bits, so for a list of up to 4 titles out of 4 could be done in a single register.
That is if order in which titles should be played is important. If you just need to flag what titles to play then register can be used to flag 16 titles ;)
Actually navigation for what you want to do is fairly simple and easy to do with PgcEdit or DvdReMake Pro. Menus to offer user a selection of needed titles that show what was already selected - this is a real pain to do manualy.
Edited: Ops. Just realized. Making menus is not that bad if you can have selection for each title separately. You will need to make just N_TITLES menus.
iJump
21st October 2005, 09:16
For storing the order, if the number of areas is limited and no repitition, then just make a list ordering the areas.
For example, say there are 15 areas.
Gprm1 corresponds to area1.
Gprm2 " " area2.
etc.
When user selects the order, put the corresponding order number in area's gprm.
For example, area2 is chosen first, so gprm2 = 1.
Area9 is chosen second, so gprm9 = 2.
Save one gprm to keep current position when playing back areas. You will have to cycle through the gprms each time to find the next area to play.
Other similar tricks are possible for more areas but you are limited by 16x16 bits of storage and it would get messier with bit arithmetics.
The playback of the areas would be non-seamless. If you wanted seamless, then you would have to do n! multi-stories and find an appropriate multiplexer, like future muxman.
Dimad
21st October 2005, 17:50
The playback of the areas would be non-seamless. If you wanted seamless, then you would have to do n! multi-stories and find an appropriate multiplexer, like future muxman.
Ideally, yes. But in some cases it is possible to do it without real seamless multiplexing:
http://cdr-zone.com/forum/viewtopic.php?t=3156&highlight=seamless
auenf
24th October 2005, 14:02
http://www.dvdstudiopro.ch/english/Advanced/playlist2a.html
any authoring software that will let you manipulate GPRMs will let you do programmable playback, however, that only has a downloadable project (or downloadable compiled video_ts)
Enf...
Cheesus
24th October 2005, 23:56
Anyone got an example that can do more than 15? That seems to be the limit at the moment.
iJump
25th October 2005, 00:42
If you divide the 256 bits throughout the 16 registers into groupings of 6, you get 44 variables with values possible from 0 to 63. Thus, you could have 44 areas/titles with this scheme. I think the math is kind of right but I'm not going to attempt to do an example.
Also, you could do a hash table type of thing where you have predefined permutations for values of the gprms. This will really boost the number of possibilities but even more programming than the bit math above. Here, we would be limited by 2 to power 256 (treating all 256 bits as one integer), which would be equal to n! I think in this case, you would get something like 57 areas/tracks, assuming each track is used once and once only. Again, I'm not going to attempt an example. To illustrate though:
Say if gprm1 = 24. if you look it up in a hash table (for dvd, this would all have to coded brute force), you might get a permutation like play titles 2,53, 23, etc.
Cheesus
25th October 2005, 01:26
Thanks iJump
I get the maths part, I just don't get how you would program Scenarist to split up the GPRM's or how you would program and store a hash table.
iJump
25th October 2005, 02:02
You would have to keep track of how the gprm's are split up as well as the values of the hash table on a piece of paper or spread sheet or something. Then use bit math in scenarist when storing or comparing values in your "new variables." With the hash table method, you wouldn't store the hash table in scenarist but create a function for every possible key. It would be kind of insane, but I'm working on a project now that's kind of insane. If it floats your boat...
Cheesus
25th October 2005, 02:20
I think I need to go back to school and relearn some maths. I knew I should've listened at the time but it was much more fun throwing paper balls ;)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.