02:10.14 | *** join/#picogui merlin262 (~andrew@crtntx1-ar1-4-60-252-139.crtntx1.dsl-verizon.net) |
02:12.37 | *** join/#picogui Oktal (mat@pc1-rdng3-5-cust219.winn.cable.ntl.com) |
02:41.39 | *** join/#picogui prae (~prae@sherpadown.net) |
03:38.17 | *** join/#picogui gonkulator (~brandon@h-69-3-48-108.DNVTCO56.covad.net) |
03:38.47 | fragglet | can anybody hear me? |
03:39.02 | gonkulator | fragglet: I can |
03:39.09 | fragglet | yay |
03:43.17 | fragglet | gonkulator: did you see my latest project |
03:43.31 | gonkulator | fragglet: nope |
03:43.39 | fragglet | http://irmo.sourceforge.net/ |
03:44.16 | scanline | oh, I remember you mentioning the idea for this |
03:44.18 | scanline | cool :) |
03:44.39 | fragglet | :) |
03:44.51 | fragglet | i need to turn irmoroids into a proper game, its a bit lacking at the moment |
03:45.54 | scanline | I really wanted to extend JetCOW to be network transparent.. so everything's a JetCOW object that you 'check out' from the server, and receive notifications whenever other clients modify that object until you check it back in |
03:46.11 | fragglet | hmm interesting |
03:46.23 | fragglet | irmo is done more centralised |
03:46.33 | fragglet | all the object changes are done server side |
03:46.54 | fragglet | if you want to create some change you can call a method from the client side |
03:47.17 | fragglet | or set up a client side "world" and have an object representing the state of input devices |
03:48.25 | scanline | does it use transactions? |
03:48.37 | fragglet | transactions? |
03:49.02 | scanline | like database transactions |
03:49.17 | fragglet | i havent studied databases much :) |
03:49.22 | scanline | this is a silly example, but let's say you have a player's X and Y positions in separate objects |
03:49.28 | scanline | so one client updates both... |
03:49.44 | scanline | but let's say another client receives the change for X first, updates the player, then it ends up inside a wall or something |
03:49.56 | fragglet | oh |
03:50.02 | scanline | transactions are a way of making an atomic group of changes |
03:50.03 | fragglet | yeah kind of i suppose |
03:50.16 | fragglet | though its more an implicit thing |
03:50.21 | scanline | in databases they're mainly so that if the server crashes, the transaction is always either completely committed to the database or not at all |
03:50.30 | fragglet | it sends updates in the form of atomic changes to the game world |
03:50.35 | captain_proton | well |
03:50.44 | captain_proton | transactions have the benefit of being atomic |
03:50.46 | fragglet | a change can affect multiple variables within an object |
03:50.56 | captain_proton | but mostly its a performance thing for changes that affect large portions of a database |
03:51.07 | scanline | bah, performance is just an optimization |
03:51.10 | fragglet | so if you modify x and y, they'll get put in the same atomic change |
03:51.25 | scanline | fragglet: well, that's why I made a silly example where X and Y were separate objects |
03:51.32 | fragglet | oh right |
03:51.33 | captain_proton | scanline: with RDBMS', performance is everything |
03:51.36 | scanline | let's say it's an adventure game and the player grabs a key |
03:51.54 | scanline | you'd want to update the player's inventory to include that key, and remove the key from a list of available items maybe |
03:52.00 | scanline | if only one of these changes happen, the player's stuck |
03:52.17 | scanline | well, or the player has two keys :) |
03:52.30 | fragglet | hrm |
03:52.51 | scanline | captain_proton: but this is a theoretical discussion... theory and performance are practically opposite areas of computer science :) |
03:54.10 | scanline | fragglet: yaknow, the stuff irmo is doing overlaps a lot with what Om will need to do |
03:54.27 | fragglet | Om is the system for the next version of picogui isnt it |
03:54.32 | scanline | among other things |
03:54.52 | scanline | but most of pg2's architecture will be based on client-server objects being observed |
03:55.37 | scanline | when you change the text in a button, the layout engine will have been observing that text for changes, so it automatically resizes the button.. then the I/O server will have observed a change in the scene graph, so it renders the change |
03:56.38 | fragglet | i vaguely heard some stuff about it |
03:56.45 | fragglet | but havent really investigated |
03:56.48 | fragglet | it sounds interesting though |
03:57.06 | scanline | well, there isn't really anything there except vague ideas and concepts yet :) |
03:57.55 | scanline | hmm.. methinks I can increase the bit rate of MythTV's MPEG-4 encoder a bit... now it's only using about 200MB per hour |
03:58.12 | fragglet | heh |
03:58.20 | fragglet | as with all things in picogui, it sounds like the way all guis should be done |
03:58.28 | scanline | =) |
03:59.35 | scanline | captain_proton: maybe later we could write a new frontend to MythTV... a lot of the backend infrastructure for it works really nicely, but the Qt-based frontend it uses is slow and kind of funky |
04:00.02 | scanline | kind of scary how they manage to abuse Qt and Xv overlays at the same time |
05:22.35 | *** join/#picogui CIA (~CIA@12-252-175-3.client.attbi.com) |
05:23.29 | *** join/#picogui CIA (~CIA@12-252-175-3.client.attbi.com) |
05:23.55 | *** join/#picogui CIA (~CIA@12-252-175-3.client.attbi.com) |
10:08.39 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
10:21.23 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
11:51.42 | *** join/#picogui prae (~prae@sherpadown.net) |
12:31.13 | *** join/#picogui TD (~mike@81-6-253-103.dyn.gotadsl.co.uk) |
13:52.33 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
13:53.00 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
13:57.00 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
15:43.27 | *** join/#picogui DevGirl (maisa@200.203.12.232) |
15:49.44 | *** part/#picogui DevGirl (maisa@200.203.12.232) |
16:24.55 | *** join/#picogui TD (~mike@81-6-253-103.dyn.gotadsl.co.uk) |
16:58.09 | *** join/#picogui Tal-DCed (~talez@talez.arach.net.au) |
18:14.07 | TD | <PROTECTED> |
18:14.10 | TD | win32 is fine |
18:14.16 | TD | free ideally :) |
19:38.40 | *** join/#picogui Oktal (~mat@pc1-rdng3-5-cust219.winn.cable.ntl.com) |
19:57.33 | *** join/#picogui trippy (~sf308@zeus.jesus.cam.ac.uk) [NETSPLIT VICTIM] |
19:57.44 | *** join/#picogui prot-work (~jupiter@161.97.199.99) |
20:02.05 | *** join/#picogui fragglet (~fraggle@pc1-glfd1-4-cust116.glfd.cable.ntl.com) [NETSPLIT VICTIM] |
20:08.30 | *** join/#picogui fragglet (~fraggle@pc1-glfd1-4-cust116.glfd.cable.ntl.com) [NETSPLIT VICTIM] |
20:08.41 | *** join/#picogui fragglet (~fraggle@pc1-glfd1-4-cust116.glfd.cable.ntl.com) [NETSPLIT VICTIM] |
20:22.26 | *** join/#picogui fragglet (~fraggle@pc1-glfd1-4-cust116.glfd.cable.ntl.com) |
20:33.19 | *** join/#picogui TD (~mike@81-6-253-103.dyn.gotadsl.co.uk) |
21:16.14 | *** join/#picogui Oktal (mat@pc1-rdng3-5-cust219.winn.cable.ntl.com) |
21:48.27 | *** join/#picogui CIA (~CIA@12-252-175-3.client.attbi.com) |
21:49.53 | *** join/#picogui captain_pistachi (~blardebla@12-203-245-57.client.attbi.com) |