| 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) |