[00:31:21] <-- Maighstir has left IRC (Quit: .)
[04:36:36] <-- gembot has left IRC (Ping timeout: 240 seconds)
[04:39:34] <-- joneirik has left IRC (Remote host closed the connection)
[04:57:36] --> gembot has joined #gemrb
[06:08:30] --> Beh0lder has joined #gemrb
[06:08:37] <Beh0lder> hi all
[06:08:44] <brad_a> hey
[06:45:58] <-- brad_a has left IRC (Quit: brad_a)
[07:18:59] --> lynxlynxlynx has joined #gemrb
[07:18:59] <-- lynxlynxlynx has left IRC (Changing host)
[07:18:59] --> lynxlynxlynx has joined #gemrb
[07:18:59] --- ChanServ gives channel operator status to lynxlynxlynx
[07:44:05] <Beh0lder> Any news about journal in Russian PST? If I can help with it, i do.
[08:10:48] <lynxlynxlynx> you said it crashes?
[08:14:52] <Beh0lder> no, journal not creating after first scene. possible script is not started
[08:21:38] <lynxlynxlynx> can you run gemrb under gdb?
[08:30:40] <Beh0lder> I'll try.What part of source i need to inspect?
[08:31:38] <lynxlynxlynx> break on GameScript::AddJournalEntry
[08:31:51] <Beh0lder> ok
[08:46:01] <lynxlynxlynx> hmm, doesn't seem the correct one
[08:46:21] <lynxlynxlynx> i don't have pst dialogs handy
[08:46:45] <fuzzie> should be Game::AddJournalEntry
[08:50:26] <fuzzie> but the first scene doesn't create the journal
[08:50:34] <fuzzie> the scene when you go through the door creates the journal
[08:50:50] <lynxlynxlynx> no, the first talk also has a journal entry
[08:50:59] <fuzzie> really?
[08:51:00] <lynxlynxlynx> end node 550
[08:51:09] <fuzzie> unmodded install?
[08:51:14] <lynxlynxlynx> I've started writing down my experiences
[08:51:23] <lynxlynxlynx> i'm pretty sure
[08:52:05] <lynxlynxlynx> yep, only widescreen was applied
[08:58:30] <fuzzie> hmph, can't reproduce, maybe i broke this install
[08:58:37] <fuzzie> i will dig out CDs. but not now, as usual.
[08:59:59] <lynxlynxlynx> it's 24933 btw
[09:00:10] <-- PixelScum has left IRC (Ping timeout: 258 seconds)
[09:01:00] <lynxlynxlynx> the other end nodes i see don't have a journal entry
[09:01:30] <Beh0lder> i posted link to russian dialog.tlk some days ago
[09:01:41] <fuzzie> it isn't relevant, afaik
[09:01:50] <fuzzie> since it doesn't modify the dlg
[09:04:35] <Beh0lder> russian patch replace only tlk and some bam files (fonts)
[09:06:29] <fuzzie> the path i get is that, after you go through the door, Morte eventually offers you two pieces of advice, then says you should start writing stuff down, TNO says he would if he had his journal, Morte says start a new one --> journal entry
[09:07:03] <fuzzie> (plus display of the NOTE: about how to access your journal)
[09:07:23] <lynxlynxlynx> there's about 10 end nodes for the first talk and only one has a journal
[09:07:34] <fuzzie> you're sure that isn't modded? :)
[09:07:50] * edheldil speaks with a hollow voice: Update my journal
[09:07:55] <edheldil> Updated
[09:07:56] <edheldil> grr
[09:08:19] <fuzzie> there shouldn't be anywhere near 10 branches in the first talk.
[09:08:42] <edheldil> what dialog is it?
[09:08:48] <fuzzie> dmorte.d i assume
[09:08:54] <fuzzie> erm, dmorte.dlg
[09:08:59] <lynxlynxlynx> dmorte1
[09:09:15] <lynxlynxlynx> most are "ignore morte .(..)"
[09:09:33] <fuzzie> ah
[09:09:36] <fuzzie> hey i have that one.
[09:10:03] <fuzzie> only one exit node though.
[09:11:12] <lynxlynxlynx> search for #550
[09:11:14] <fuzzie> if you really have 10 end nodes then I can only imagine you have Restored More Morte Mortuary Moments installed.
[09:12:10] <fuzzie> http://184.108.40.206/~fuzzie/nfs/gemrb/dmorte1.txt (although bear in mind 'maybe i broke this install' disclaimer above)
[09:12:23] <lynxlynxlynx> hmm, it is in override
[09:12:34] <lynxlynxlynx> it'd have to be a nonweidu mod or part of the cds though
[09:13:56] <edheldil> dmorte1 has only 35 states
[09:16:08] <edheldil> I have no dmorte1 in override, just dmorte
[09:22:52] <Beh0lder> I speak with Dhal in mortuary and found new entry in journal! But in original game i get first entry after first scene with Morte. Odd...
[09:25:05] <edheldil> btw, afaics in dmorte1 there's nothing which would add the journal - it has to be some other dialogue
[09:25:25] <fuzzie> you should really get it after going through the first set of doors.
[09:25:34] <fuzzie> i checked some youtube playthroughs.
[09:30:31] <Beh0lder> post a link to video please
[09:31:16] <edheldil> it's in dmorte2, states 9,10,11 - but there's nothing to really add/create journal, just exit. So it has to be in some script?
[09:31:23] --> Yoshimo has joined #gemrb
[09:31:48] <fuzzie> well, for example look at ~19:50 of http://www.youtube.com/watch?v=HWOuKSxqpbA
[09:31:56] <fuzzie> edheldil: state 11 should have a journal attached.
[09:36:58] <edheldil> ah, right - transition 21 has flag 'journal entry' and a journal text!=0
[09:43:00] <Beh0lder> Heh, this dialog is not displayed for me
[09:43:50] <fuzzie> so, the bug is: you get no dialog when you go through the door?
[09:44:55] <Beh0lder> Yes. I open the door, and come in new room, no dialogs.
[09:53:07] <lynxlynxlynx> what's the trigger?
[09:55:27] <edheldil> do you know what area it is?
[10:14:08] <Beh0lder> I'll try to play gog version, may be my current version of pst is broken
[10:22:21] <edheldil> as far as I can Find, it's caused by trigger 0202TRG1 in AR0202
[10:29:53] <edheldil> err, script 0202TRG1. But I do not see what is it bound to
[10:36:16] <edheldil> oops, it's that proximity trigger, I was blind
[10:59:18] <Beh0lder> how to configure gog version?
[10:59:28] <Beh0lder> it has no CD[X]
[10:59:50] <Beh0lder> I set all paths to game root but it's not work
[11:00:09] <Beh0lder> no movies & blue screen
[11:01:30] <fuzzie> work out where bif files are
[11:06:34] <Beh0lder> bif files are in game root and in data folder
[11:08:20] <lynxlynxlynx> just set gamepath then
[11:09:16] <Beh0lder> I set it to root folder
[11:26:22] <edheldil> if they are in data, you might not find them if you set GamePath to game root
[11:26:37] <edheldil> err, if you set cdpath
[11:26:55] <edheldil> try setting cdpath to gameroot/data
[11:32:15] <Yoshimo> this video fuzzie linked has some strange kind of humor^^ "tighter than a chastity belt"
[11:37:00] <edheldil> actually this phrase is used about 5 times :)
[11:37:09] <edheldil> "We and me boys had just popped this crypt... and it was harder than picking a chastity belt, I'm tellin' ye. ...."
[11:39:17] <edheldil> Beh0lder: if you have pristine GOG installation, what about using something like this http://www.eowyn.cz/gemrb/create_manifest.sh on the media and/or install dir and send me the result?
[11:57:33] --> Micru has joined #gemrb
[12:12:32] <Yoshimo> big world setup says one cant install more than 9 priest packs, is that an arbitrary limit by the vanilla engine?
[12:17:41] <lynxlynxlynx> yes, since they're kits
[12:17:55] <lynxlynxlynx> not a problem for gemrb
[12:24:07] <Yoshimo> id exspected this message to go away when seleting tobex^^ oh well
[12:25:36] <-- Micru has left IRC (Quit: Page closed)
[12:43:30] <Beh0lder> edheldil, I'm a windows user. can't use sh scripts))) Maybe if i copy all bif files to Data folder, gemrb will to work?
[12:44:32] <edheldil> rather better chances the opposite way - if you would copy all files to the game root dir.
[12:44:41] <edheldil> But why would you do that?
[12:44:53] <fuzzie> nothing stopping a windows user from using sh scripts :P
[12:45:01] <edheldil> You should be able to see in console while bif file it can't find
[12:45:12] <fuzzie> but yes, give us the log if you can't work it out
[12:46:36] <edheldil> while-which
[13:00:59] --> duckpunch has joined #gemrb
[13:03:33] <Yoshimo> whats so special about "gog" that lynx even wants to do a videotutorial about it? ;)
[13:08:36] <Beh0lder> http://aom-game.org/download/log.txt
[13:11:04] <Beh0lder> These files are in the data folder.
[13:11:34] <Beh0lder> ar0500.bif and other
[13:11:49] <fuzzie> did you set CDx to point at the data folder?
[13:12:06] <lynxlynxlynx> Yoshimo: it will be about gemrb, gog is just a good source of the games
[13:12:08] <Beh0lder> no, i'll try
[13:14:36] <Beh0lder> it works, i set all cd paths instead cd1 to data
[13:14:46] <Beh0lder> thank you
[13:17:42] <Beh0lder> script not works in gog version too
[13:18:05] <Beh0lder> dialog not appears
[13:22:15] <lynxlynxlynx> the script has no dialog unless volname spawns it
[13:22:20] <lynxlynxlynx> it will continue anyway
[13:23:50] <Beh0lder> this dialog appears in original, i checked
[13:25:02] <Beh0lder> another bugs - 1. If I close container, not an all GUI redraws. Clock in left-down corner not displaying
[13:26:09] <Beh0lder> 2. Items not accumulating in inventory, such as bandage
[13:26:49] <Beh0lder> 3. I can't use items from inventory ('use' button is not displayed).
[13:26:57] <lynxlynxlynx> oh, i thought you meant edheldil's hasher
[13:29:10] <edheldil> Beh0lder: you should probably see some exception in console for bug 1
[13:31:15] <Beh0lder> Can I start pst in windowed mode? it's hard to read logs if game in fullscreen
[13:31:36] <edheldil> Full screen=0 in torment.ini, I believe
[13:35:57] <Beh0lder> no exceptions
[13:37:43] <Beh0lder> only this: [GameControl]: More than one bottom window!
[13:43:57] <Beh0lder> I can't use items from quick menu too
[14:36:11] <CIA-44> GemRB: 03lynxlupodian * r15ee553bf668 10gemrb/gemrb/core/GUI/GameControl.cpp: don't prevent casting on invisible actors when they're the ones casting
[14:36:14] <CIA-44> GemRB: 03lynxlupodian * r4e70876671c2 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: made GemRB_GetKnownSpellsCount accept globalIDs and improved GemRB_GetKnownSpell's pydoc
[14:48:04] <CIA-44> GemRB: 03lynxlupodian * r268183cc0a3f 10gemrb/gemrb/ (6 files in 5 dirs):
[14:48:04] <CIA-44> GemRB: implemented SetupSpellIcons in the guiscript and made use of it in bg2
[14:48:04] <CIA-44> GemRB: also added a new table that enables customisable sorting of the spell list
[14:48:04] <CIA-44> GemRB: todo: innates were broken, so they're still disabled
[14:48:04] <CIA-44> GemRB: todo: use it in other games; it is still disabled, even though it had rigorous testing
[14:48:04] <CIA-44> GemRB: todo: mentioned todos
[14:48:54] <lynxlynxlynx> try to break it
[14:56:59] <edheldil> you have mentioned the todos, so you should remove that line ;-)
[14:58:54] * edheldil gets ready to suggest to lynx to rename himself to "git reset --hard d95c38edecb638f1586fdb09d859ed4191a3610b"
[14:59:45] <lynxlynxlynx> in-source mentions :P
[15:09:32] <Yoshimo> edheldil: what happens if you execute this new nick? ;)
[15:10:27] <edheldil> :)
[15:10:54] <edheldil> it's the first revision commited to git
[15:11:43] <edheldil> although it goes only to 2003, apparently we had thrown away CVS history back then
[15:13:46] <edheldil> ah, no, it really is the very first (or, rather the one before it) commit of GemRB to SF repo
[15:14:03] <CIA-44> GemRB: 03lynxlupodian * rd7b0e7f29637 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: added a GET_ACTOR_GLOBAL macro to merge the functionality
[15:16:35] <edheldil> I wonder whether the SVN revisions are the same as svn-ids, as r1 seems to be done by wjp :)
[15:16:44] <edheldil> btw, just the other day I have found an archived irc log, when I have joined this channel for the first time :)
[15:16:50] <fuzzie> edheldil: as part of cvs->svn?
[15:17:23] <edheldil> fuzzie: I mean, 2003 - was it really wjp?
[15:17:39] <edheldil> commit d95c38edecb638f1586fdb09d859ed4191a3610b
[15:17:39] <edheldil> Author: Willem Jan Palenstijn <email@example.com>
[15:17:39] <edheldil> Date: Thu Oct 2 12:00:00 2003 +0000
[15:17:39] <edheldil> repository structure
[15:17:39] <edheldil> svn-id: r1
[15:17:46] <fuzzie> i mean, i assume it's a faked revision as part of a migration from cvs to svn.
[15:18:10] <edheldil> rather from svn to git, I assume
[15:18:12] <fuzzie> no
[15:18:21] <fuzzie> that would make less sense
[15:19:48] <edheldil> had it been in svn, it would have a different author, would not it?
[15:19:56] <edheldil> have had
[15:20:17] --> brad_a has joined #gemrb
[15:20:25] <edheldil> Hi, brad_a
[15:20:41] <brad_a> good morning/afternoon
[15:21:06] <fuzzie> edheldil: wjp didn't do the cvs->svn migration?
[15:21:28] <edheldil> I might look a bit nitpicky, but actually fonts originally had all the properties you are mentioning with BAMs :)
[15:21:54] <fuzzie> which properties?
[15:22:12] <edheldil> like being bitmaps :)
[15:22:42] <fuzzie> not how they're implemneted in gemrb though?
[15:22:43] <edheldil> s/originally/before TTF, Type1/
[15:22:54] <fuzzie> oh
[15:23:09] <fuzzie> well, that is why no-one took them very seriously :p
[15:23:57] <edheldil> I meant that not so very long ago I had many more bitmap fonts than the vecor ones in my system :)
[15:25:13] <fuzzie> you may have a "so old that you are scary" hat and join us in the corner
[15:25:23] <edheldil> not that it matters :)
[15:28:23] <edheldil> sorry!
[15:29:17] <lynxlynxlynx> hehe
[15:51:36] <wjp> edheldil: I'm pretty sure fuzzie is right
[15:52:22] <wjp> "repository structure" is a typical first svn commit, but not in cvs and git
[15:52:33] <wjp> so it was added when going cvs->svn
[15:52:59] <edheldil> wjp: you really did that r1 commit in 2003? Ah, then sorry, did not realize it SO long you are aboard :)
[15:53:09] <wjp> no, I faked the date to keep them linear
[15:53:18] <wjp> svn gets confused if dates are out of order
[15:53:40] <wjp> whoever did the svn->git conversion should really have killed this commit again
[15:54:14] <edheldil> ahh, I get it. r2 is actually the first cvs commit
[15:54:17] <wjp> yes
[15:55:03] <edheldil> I was confused :)
[15:56:17] <wjp> be glad you're forgetting about the bizarre details of cvs and svn repositories :-)
[16:00:31] <Yoshimo> im glad i only have to worry about git pull
[16:04:11] <-- brad_a has left IRC (Quit: brad_a)
[16:09:57] <lynxlynxlynx> http://justinhileman.info/article/git-pretty/git-pretty.png
[16:11:23] <-- duckpunch has left IRC (Quit: Lost terminal)
[16:11:41] <wjp> nice :-)
[16:12:51] <wjp> "Do you hate them?" :-)
[16:19:56] --> brad_a has joined #gemrb
[16:24:45] --> Maighstir has joined #gemrb
[16:29:50] <-- gembot has left IRC (Ping timeout: 260 seconds)
[16:34:49] <brad_a> is there anyway to attach valgrind to a running process?
[16:34:58] <brad_a> probably not
[16:36:07] --> gembot has joined #gemrb
[16:36:17] <Yoshimo> from the faq:
[16:36:18] <Yoshimo> Is it possible to attach Valgrind to a program that is already running?
[16:36:18] <Yoshimo> No. The environment that Valgrind provides for running programs is significantly different to that for normal programs, e.g. due to different layout of memory. Therefore Valgrind has to have full control from the very start.
[16:36:34] <brad_a> figured. thanks.
[16:36:37] <CIA-44> GemRB: 03tom.prince * rb1bdbf73036d 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: Use Py_BuildValue, rather than PyTuple_New and PyTuple_SET_ITEM.
[16:37:07] <brad_a> its ok tho cuz i believe i found instructions on how to use it with the iOS simulator
[16:38:14] <edheldil> lynxlynxlynx: niiice, just sent it to my colleagues as a git manual :)
[17:01:05] <lynxlynxlynx> tomprince: i get build errors on the guiscript changes
[17:01:26] <lynxlynxlynx> something is fishy though, since you didn't change what it claims to be the problem
[17:02:17] <lynxlynxlynx> ah, i see
[17:03:47] <CIA-44> GemRB: 03lynxlupodian * rd9c10f38e099 10gemrb/CMakeLists.txt:
[17:03:47] <CIA-44> GemRB: Revert "don't treat unknown pragmas as errors"
[17:03:47] <CIA-44> GemRB: not needed anymore
[17:03:47] <CIA-44> GemRB: This reverts commit 53004daa26c069b195a9a6d85099b0af8da2585a.
[17:03:58] <CIA-44> GemRB: 03lynxlupodian * rc431e8859b3e 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: fixed typos from b1bdbf73
[17:05:55] <brad_a> tomprince: thanks :)
[17:07:40] --> Drakkar has joined #gemrb
[17:15:22] <CIA-44> GemRB: 03lynxlupodian * r22e6c86f08fd 10gemrb/NEWS: regular NEWS bump
[17:19:01] <brad_a> I'm still mulling over on how to do a set palette with fonts done as sprite arrays. any ideas on how it should be done?
[17:21:21] <tomprince> I had fixed that, but obviously forgot to ammend the commit. :(
[17:22:47] <wjp> brad_a: I haven't been following what you're doing exactly, but would it be possible to override the palette in the blit command instead?
[17:23:31] <wjp> (not all Blit functions have a palette option though)
[17:23:40] <brad_a> well sure (i think) i'm just dont know what the best way is and you all know much more than me of any slick tricks
[17:25:20] <brad_a> but is that any better than just setting the palette before every blit in the print function?
[17:25:33] <brad_a> neither seem very ideal
[17:26:01] <brad_a> and looping though every sprite on every set pallete seems bad too
[17:27:12] <brad_a> and copying the palete data to a special palette that they are all pointing to doesnt sound good
[17:28:03] <wjp> why is a "blit sprite with palette" call worse than "set palette; blit sprite" ?
[17:28:12] <fuzzie> btw i thought of reason this is a bad thing to change: opengl textures.
[17:28:24] <wjp> hm, there is that
[17:30:20] <brad_a> well there is no reason it HAS to be changed
[17:30:27] <brad_a> i was told it was a good thing
[17:30:30] <brad_a> :)
[17:31:02] <brad_a> also that might hold water if i thought anybody would ever get around to doing some opengl stuff :)
[17:31:09] <wjp> random ignorant question: would we have to make the sprite more 'square' for a texture?
[17:33:18] <-- gembot has left IRC (Ping timeout: 245 seconds)
[17:35:10] <-- tomprince has left IRC (Ping timeout: 255 seconds)
[17:38:47] <brad_a> so… we want to keep the big font sprites?
[17:40:49] --> tomprince has joined #gemrb
[17:43:21] <fuzzie> wjp: would be better i think but don't know.
[17:44:01] <tomprince> Well, Well, we do
[17:44:52] <fuzzie> brad_a: i dooon't know.
[17:45:00] <fuzzie> i am at 'afternoon coffee' stage.
[17:45:48] <fuzzie> just thinking of potential really annoying things.
[17:48:36] <brad_a> well good. somebody has to :)
[17:49:26] <fuzzie> my completely uninformed from-the-internet wisdom is that switching textures is slow and it's a lot more efficient to pack them into one sprite from the Font side than trying to hack something up on the driver side
[17:50:20] <fuzzie> but maybe we have to do smart things for BAMs anyway, so it has to be on driver side..
[17:51:10] <tomprince> Well, do we need to have sprites correspond to textures?
[17:51:52] <fuzzie> well, if not, then that would fall under 'hack something up on the driver side'
[17:51:54] <wjp> not necessarily 1-to-1
[17:52:01] <wjp> right
[17:52:05] <tomprince> Yes, laggy connection. :)
[17:52:30] <fuzzie> ah, ok.
[17:52:46] <fuzzie> well, good that you also had that thought quickly then :P
[17:53:57] <fuzzie> so my thought is 'as long as we can somehow bundle these sprites together at creation time'
[17:54:02] <fuzzie> i haven't looked at how brad_a is creating them now
[17:54:28] <brad_a> now im taking an array of sprites and copying their pixels into a big buffer
[17:54:36] <brad_a> to make 1 big sprite like we have now
[17:54:52] <brad_a> tomprince said it would be better to just keep it as an array
[17:55:04] <fuzzie> but you could just tell the video driver 'ok, start sprite batch' and 'ok, stop sprite batch' at beginning/end
[17:55:13] <brad_a> what?
[17:55:23] <fuzzie> and then it could shove them all into one big sprite
[17:55:25] <wjp> I think we're in 'hack something up' territory again :-)
[17:55:37] <fuzzie> so an array of sprites is fine i think.
[17:55:59] <brad_a> but is it better?
[17:56:08] <fuzzie> i mean, assuming you are actually creating the sprites and not hacking into Sprite2D internals :)
[17:56:11] <brad_a> i man we get rid of a blitter we wouldnt need
[17:56:24] <fuzzie> and that is what i meant by that i'm not sure how you're creating them now.
[17:57:52] <brad_a> well the bams are not hacked and i wouldnt call the ttf ones hacked per se. the only problem with them is SDL_ttf creates them and owns their pixel data so we have to work something out so the video driver doesnt try to free those pixels
[17:58:01] <fuzzie> brad_a: well, the alternative would be to try and do something clever and make them a *proper* sprite sheet
[17:58:06] <brad_a> unfortunately SDL docs say that the flag is internal and private
[17:58:10] <fuzzie> and that does sound like it lives in video driver
[17:58:37] <brad_a> what is a "proper" sprite sheet?
[17:59:06] <fuzzie> something which tries and packs the sprites together as best as possible, such that the result is square and has power-of-2 dimensions
[17:59:13] <fuzzie> i guess.
[17:59:20] <brad_a> bah
[17:59:23] <fuzzie> and by 'hacked' i mean poking inside Sprite2D_BAM_Internal that's all :)
[17:59:24] <brad_a> :-P
[17:59:30] <brad_a> no never touched it
[18:00:05] <wjp> as I said before, I don't know what exactly you're doing, but why doesn't "just" adapting BAMImporter::GetFont() for the ttf case work?
[18:00:08] <fuzzie> anyway these are just random thoughts.
[18:00:57] <brad_a> wjp thats essentially what im doing now
[18:01:14] <wjp> ah, ok
[18:01:37] <brad_a> my way may have more setup overhead i guess but the end result is the same
[18:01:56] <brad_a> and i dont really care about 2 seconds more startup time for simpler coe (IMO)
[18:02:28] <fuzzie> for just ascii range in ttf, i don't see why it would take any time you'd ever notice
[18:03:06] <brad_a> but since i ws dealing with sprite arrays already i guess we figures it may be better to jsut keep them that way so we can get rid of blit by region and some other things
[18:03:16] <brad_a> fuzzie: it doesnt
[18:03:43] <brad_a> also my code reuses fonts if you are using the same one so it can be quicker depending on how you have configured fonts.2da
[18:03:44] <fuzzie> ok. just as long as you don't mean 2 seconds, because '2 seconds' tends to blossom into several minutes :P
[18:04:04] <brad_a> :-p yeah i was exagerating
[18:04:13] <wjp> 2 seconds is an eternity :-)
[18:04:35] <brad_a> the difference is immeasurable to me
[18:05:29] <brad_a> also i have made it so you can limit the glyph range for both bam and ttf fonts so you can save memory etc by trimming what you dont need
[18:06:20] <fuzzie> well
[18:06:33] <fuzzie> i guess an important point here is: this maybe only works well as long as the BAM sprites are passed on directly
[18:06:37] <tomprince> The problem is that SDL_ttf creates an SDL surfaces directly, and SDLVideo doesn't expose a way to create a sprite from a surface.
[18:07:15] <fuzzie> right, but you really don't want to be doing that anyway
[18:07:40] <brad_a> right and you didnt like my copying it and freeing the old one :-P
[18:08:07] <fuzzie> i mean, copying the contents of the sprites out is the only thing which you can do there, right?
[18:08:09] <wjp> there's no need to go through SDLVideo just to get at the contents of an SDL_Surface created by SDL_ttf
[18:08:26] <brad_a> originally i asked the video driver for a sprite from the surface pixels then discarded the old surface
[18:09:17] <wjp> I'm kind of failing to see any problem. Font::AddChar just accepts raw pixel data, doesn't it?
[18:09:30] <wjp> But maybe I'm just completely missing what you're discussing :-)
[18:09:31] <brad_a> yes but i destroyed that
[18:09:40] <wjp> ah
[18:10:42] <brad_a> also it didnt work with sdl_ttf stuff
[18:10:48] <fuzzie> asking the video driver for a sprite from the surface pixels then discarding the old surface sounds like the Right Thing
[18:10:59] <brad_a> because it assumed that the pitch was always width of the glyph
[18:11:31] <wjp> that's a one line fix though :-)
[18:11:39] <brad_a> fuzzie: thats what i was doing but tom said he didnt like creating a usable surface copying it then destrying the old one.
[18:11:52] <brad_a> wjp: how?
[18:12:02] <wjp> add a pitch argument to AddChar :-)
[18:12:07] <brad_a> ah
[18:12:13] <wjp> but that's of course irrelevant if that no longer exists
[18:12:14] <fuzzie> brad_a: i am looking at logs and i think you two just got confused about what the other was saying maybe
[18:12:25] <brad_a> this was a long time ago
[18:12:32] <fuzzie> i think tomprince was saying, just make the sprite properly, don't muck with the vptr
[18:12:36] <brad_a> after the first time i showed my work
[18:13:26] <brad_a> well he also went and made a sprite constructor soley for the purpose of me using that instead
[18:13:36] <wjp> hm, IIRC, sprites should never be created by other things than the video driver
[18:13:44] <fuzzie> my next question is to wonder why vptr is public :(
[18:13:59] <brad_a> it probably shouldnt be
[18:14:05] <fuzzie> well
[18:14:23] <fuzzie> the visibility lines inside Sprite2D are 'public:', 'public:', 'public:' and then 'public:'
[18:14:33] <brad_a> :-P
[18:14:36] <tomprince> Well, the trick is *SDL*_ttf depends ond SDL.
[18:14:53] <fuzzie> tomprince: yeah, but not necessarily on SDLVideo.
[18:15:59] <fuzzie> any opengl-on-desktop or fully SDL 1.3 implementation is not going to be using SDL surfaces internally.
[18:16:36] <wjp> any SDL_ttf-using code is "allowed" to use SDL functions and access SDL structs, I would say
[18:17:16] <brad_a> well if nobody minds the overhead of my copying the pixel data from the surface and then creating a sprite from that copy and destroying the old surface that is simple change :-)
[18:17:22] <fuzzie> but both are still going to have SDL available.
[18:18:41] <brad_a> of course none of this answers if we want the font to remain one big sprite :-P
[18:18:51] <fuzzie> i am fairly sure 'no'
[18:18:59] <brad_a> ok :)
[18:19:01] <fuzzie> but feel free to worry about it some more!
[18:19:10] <brad_a> :(
[18:19:17] <fuzzie> while i am fairly sure that relying on SDL backends using SDL_Surface* as their vptr is a Really Bad Thing.
[18:19:41] <tomprince> Well, I think until we have some other backend, having SDL_ttf create the surface directly is fine. :)
[18:19:52] <fuzzie> why?
[18:20:00] <fuzzie> i mean, that's just a hack which you know we'll have to remove
[18:20:17] <fuzzie> since i'm pretty sure no-one is ever going to implement a non-SDL backend
[18:21:16] <brad_a> well its not like its hard to change
[18:21:53] <brad_a> if another video driver was created just copy the pixels from the surface and have the video driver create the sprite
[18:22:00] <fuzzie> well, i'm just looking at it from the perspective of a future person sabotaging all the ttf code because no-one can fix the hack
[18:22:27] <brad_a> must be a future where we are all dead and dont care
[18:22:35] <fuzzie> well, that happens quite a lot
[18:22:37] <wjp> I'm pretty sure the idea of vptr is that it should only be touched by the video driver
[18:22:50] <tomprince> Simply because until we have a number of backends, we don't know what the proper abstraction to build so we don't need the hack.
[18:23:12] <brad_a> good point
[18:23:26] <fuzzie> i'm not sure that's a good reason to add the hack.
[18:23:35] <brad_a> well no but the hack is already added
[18:23:45] <brad_a> and it really is super simple to change
[18:23:53] <fuzzie> so why not change it?
[18:23:56] <brad_a> i will
[18:24:00] <brad_a> :)
[18:24:02] <fuzzie> i am having difficulty understanding tomprince's reluctance
[18:24:18] <wjp> is it just the extra memcpy?
[18:24:29] <fuzzie> removing blit functions is helpful though.
[18:24:36] <brad_a> well i understand the pain of creating an object that is perfectly usable but instead creating a new copy and destroying the old
[18:24:52] <brad_a> but it still the Right Way
[18:25:13] <brad_a> wjp: yes i believe so
[18:25:24] <tomprince> Well the code I didn't like was mucking with with the vptr, setting it to a freshly created SDL_surface, if I rember correctly.
[18:25:40] <brad_a> wait something scoming back to me
[18:26:37] <brad_a> i think there meay have been a problem with assumptions that the video driver was making when creating the surface. but i think either they are irrelevant now (because im using 256 color palletes) or they could be easily remidied
[18:26:49] <brad_a> palettes
[18:27:00] <brad_a> stupid brain-finger relationship!
[18:28:12] <fuzzie> i was wondering if we can just migrate to SDL_texture for this sort of thing, for a 1.3 backend
[18:29:29] <fuzzie> but at a glance i think that's not going to be any better than SDL_surface due to severe limitations on what you can do with those
[18:31:09] <brad_a> well back to my original question: is passing a palette to the blitter the best way to handle printing fonts as individual sprites?
[18:31:40] <fuzzie> right, and that is a much trickier question
[18:32:03] <fuzzie> i would just do whatever is easiest for you right now.
[18:32:55] <fuzzie> that is definitely something which falls under "we don't know what proper abstraction to build" i think.
[18:33:03] <tomprince> Well, we probably don't need SDL_ttf, if we want to be passing pixel data to SDLVideo.
[18:33:30] <tomprince> We can just use freetype? directly.
[18:33:43] <fuzzie> right, but then it's a lot more difficult to build for people, i think
[18:33:47] <brad_a> sure it was just easier for me to do it via sdl_ttf
[18:33:49] <fuzzie> since SDL_ttf is something which gets ported
[18:34:01] <brad_a> but sdl_ttf requires freetype2 anyway
[18:34:02] <fuzzie> and freetype is sort of under there somewhere in unreliable ways
[18:34:03] <lynxlynxlynx> sdl_ttf depends on freetype
[18:34:33] <fuzzie> but i don't know how difficult it is to just build freetype ourselves.
[18:34:44] <fuzzie> and if brad_a is actually building it anyway..
[18:35:04] <brad_a> yes i am but i havent a clue how to write the cmake file
[18:35:11] <fuzzie> i know on android it looked an awful lot less painful to just go via the code already written for SDL_ttf.
[18:35:19] <fuzzie> but presumably that code could jsut be stolen.
[18:35:45] <brad_a> yes the freetype code is under sdl_ttf is a bit more complicated than i wanted to get at
[18:35:56] <brad_a> well thats true :)
[18:36:27] <brad_a> well IF we ever get something that doesnt require SDL then I will gladly rewrite to use freetype directly
[18:36:39] <brad_a> openal depends on sdl too ;-)
[18:36:48] <fuzzie> well, i doubt we will ever get a backend that doesn't
[18:36:53] <brad_a> exactly
[18:36:59] <fuzzie> since doing windowing without SDL is a nightmare
[18:37:08] <brad_a> so i may as well keep using sdl_ttf (it builds very easy)
[18:37:15] <brad_a> its only 1 or 2 source files
[18:37:23] <fuzzie> but it is inelegant i can see.
[18:37:35] <fuzzie> anyway we spent more time dicussing it than it'd ever cost now maybe.
[18:38:18] <lynxlynxlynx> back to work
[18:39:00] <brad_a> well im not against putting it on my list to get rid of the SDL_ttf dependancy and just using freetype directly but id rather get TTF working and commited first
[18:39:21] <brad_a> then come back in a couple months when im not sick of it :)
[18:40:48] <brad_a> in fact i would like it if i could get what i have cleaned up and tested more then commit that then worry about changing the font to use individual sprites as a separate task
[18:41:45] <fuzzie> do you have git repo?
[18:42:03] --> Beholder has joined #gemrb
[18:42:38] <brad_a> i have a git hub account but never got around to pushing gemrb up there
[18:42:53] <brad_a> why does that matter?
[18:43:57] <fuzzie> well, that way i can keep up-to-date with anything you have easier
[18:48:53] <brad_a> do i just branch my master and setup github as a remote for that branch?
[18:49:18] <fuzzie> i think given my level of coherence here, i am not a good person to answer that right now :)
[18:49:58] <wjp> brad_a: do you already have a fork on github of the gemrb repo?
[18:50:07] <brad_a> no
[18:50:16] <wjp> first do that (using the github web interface)
[18:50:23] <wjp> then add that as a remote to your repo
[18:50:37] <wjp> then create a branch locally, and push that to the new remote
[18:50:57] <brad_a> how do i fork? (git noob)
[18:51:18] <wjp> do you have a github account?
[18:51:28] <brad_a> yes
[18:51:33] <wjp> log in, go to the github of the main gemrb repo, and click the fork button
[18:51:35] <fuzzie> go to e.g. https://github.com/fuzzie/gemrb and hit the 'fork' button at the top
[18:51:44] <fuzzie> i think wjp is forgetting we don't have our main repo on github :P
[18:51:48] <wjp> oh
[18:51:49] <wjp> oops
[18:51:50] <fuzzie> which is easy to forget
[18:51:55] <brad_a> ah :)
[18:51:58] <fuzzie> but i think everyone branched off that one so far.
[18:52:27] <brad_a> ok forked
[18:53:27] <fuzzie> it just means you get nice graphs like https://github.com/fuzzie/gemrb/network which remind me that i haven't pushed to github since moving to another machine but tomprince clearly has.
[18:58:19] <brad_a> so now new branch locally, switch to that branch, commit some work then "git push github"?
[19:00:14] <lynxlynxlynx> git push github thatbranch
[19:00:22] <brad_a> ah
[19:00:36] <lynxlynxlynx> unless you set it up to default to that remote
[19:01:10] <brad_a> no but i probably should
[19:06:23] <-- wjp has left IRC (Ping timeout: 276 seconds)
[19:14:12] <-- brad_a has left IRC (Ping timeout: 240 seconds)
[19:25:47] --> wjp has joined #gemrb
[19:25:48] --- ChanServ gives channel operator status to wjp
[19:36:53] <-- Yoshimo has left IRC (Ping timeout: 258 seconds)
[19:41:13] --> Yoshimo has joined #gemrb
[19:52:45] --> gembot has joined #gemrb
[20:29:55] --> SiENcE has joined #gemrb
[20:35:23] --> brad_a has joined #gemrb
[20:53:37] <-- Beholder has left #gemrb
[21:48:02] --> Maighstir_ has joined #gemrb
[21:50:00] <-- Maighstir has left IRC (Ping timeout: 260 seconds)
[22:20:21] <-- Yoshimo has left IRC (Quit: Yoshimo)
[22:27:42] <-- SiENcE has left IRC (Ping timeout: 240 seconds)
[22:28:11] <-- brad_a has left IRC (Quit: brad_a)
[23:08:27] <-- lynxlynxlynx has left IRC (Remote host closed the connection)