The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Allegro Hack Day/2007 June 09/log

From Allegro Wiki
Jump to: navigation, search

All times in +0200 UTC.

Logs

14:03:52 tjaden hello
14:04:01 allefant hi
14:04:08 allefant so everyone is here now :)
14:05:37 tjaden so, who wants to go first
14:06:01 allefant well, about "display API spec", nothing much changed since last time, from my side :/
14:06:31 tjaden i was thinking if we had not much on, we could do it today
14:07:09 tjaden also trentg seems to have done a lot
14:07:20 allefant indeed
14:07:21 trentg I think we should start the display API from scratch, rather than use Evert's wrapper.
14:07:39 allefant yes, that was my conclusion as well
14:07:49 allefant but you already got much farther than me
14:08:00 allefant i.e. you got the compatibility layer working
14:08:34 trentg The compatibility layer is mostly done in software, then drawn to the screen, so it's not as accelerated as the new api.
14:08:58 allefant so "screen" is a 4.2 BITMAP?
14:09:09 trentg Yes, but I had to change BITMAP a bit.
14:09:28 trentg I added an AL_BITMAP * and a needs_upload bool.
14:09:58 trentg Only the screen use them.
14:10:54 allefant how much of the new API does work?
14:11:29 trentg Just the blitting. All of the blitting functions work now, and support all flags. The only thing left is clipping.
14:11:49 allefant also all the color depth/format stuff Bob put in there?
14:12:04 trentg Oh, not that yet either.
14:12:30 allefant i was thinking about simplifying that.. but it's hard where to start
14:12:36 tjaden which API are you implementing?
14:12:42 trentg Bob's.
14:12:44 allefant some things like the multiple-clipping rectangles would be easy to just drop though
14:13:10 trentg Yeah. That seemed a bit too much to me.
14:13:11 tjaden it's hard to know what Bob's api is
14:13:13 allefant e.g. i wouldn't even know how to do more than a single clipping rect in OpenGL, without the stencil buffer
14:14:04 trentg Yeah, and that will slow it down and is needed by other things in the API too.
14:14:25 trentg tjaden: This is what I'm working from: http://wiki.allegro.cc/NewAPI/Documents/gfx-api
14:15:10 allefant trentg: did you also see this? http://wiki.allegro.cc/NewAPI/Display
14:15:56 tjaden we still need a trimmed and revised version of that
14:16:07 allefant or did you actually make an al_create_display_bitmap, which is the same as set_gfx_mode and returns a normal AL_BITMAP
14:16:26 trentg allefant: I started with your OGL driver, so it's similar to that.
14:16:30 allefant ah, nice
14:17:02 trentg One strange thing now is that to draw to the current display, you pass NULL as the destination.
14:17:05 allefant yeah, i also think the gfx-api document is too big right now
14:17:33 allefant the idea was to drop the destination param
14:17:36 trentg I didn't think the screen should be an AL_BITMAP.
14:17:46 allefant so like: al_line(100, 100, 200, 200, red)
14:17:53 trentg Ah, OK.
14:18:34 trentg Yeah, I only briefly saw that display API you linked.
14:19:02 tjaden can we go through later and just decide what to keep and what to drop?
14:19:29 trentg Yeah, that would be good.
14:19:34 leverton yeah, I think there is too much confusion to get much progress on drivers
14:19:34 allefant yes, sounds like a good idea. myself, i couldn't really decide to drop much (except the clipping rectangles, maybe patterend drawing)
14:19:45 allefant we likely can't drop e.g. palettes
14:20:01 allefant or masking
14:20:10 mimix i have a feeling that paterned drawing is widely used
14:20:21 allefant but it's too limited
14:20:26 allefant can't even draw a dashed line with it
14:20:34 allefant so if i want patterns, i should link against libcairo instead
14:20:57 mimix it is uesd much for filled rectangles
14:21:14 mimix e.g in skater demo game
14:21:41 mimix filled triangles actually
14:21:50 allefant well, they would be a minor point anyway, so maybe they should stay
14:21:57 allefant but yeah, let's do that later..
14:22:47 leverton I think a good first milestone is simply the Display API and the blitting portion of the Graphics
14:22:59 tjaden yes
14:23:29 tjaden ok, what else for now?
14:24:02 leverton in other topics?
14:24:16 tjaden do we want a 4.3 branch soon?
14:24:59 allefant if the 4.9 branch is working soon, there would be no need for it
14:25:21 allefant but i think, we want a 4.3
14:26:26 tjaden it's not hard work integrating agl i think
14:26:38 mimix yeah, what exactly should go into 4.3?
14:26:40 allefant yep, in the way we said last
14:27:20 mimix resiazble windows? draw_sprite_*_ex?
14:27:31 allefant and AGL would be merged
14:27:40 allefant i.e. just put the source into a folder
14:27:43 tjaden AGL is the main thing
14:27:46 allefant and make easy to build
14:27:55 tjaden i think if those other features are developed, they can go in
14:28:12 mimix AGL will be the hightlight of the release, but we can put some other changes
14:28:15 tjaden we don't have such strict feature freezes anymore anyway, so could go in later
14:28:39 Hitman (n=Colin@213-162-100-166.edenri414.adsl.metronet.co.uk) has joined #allegro-dev
14:28:39 ChanServ gives voice to Hitman
14:29:15 allefant i think 4.4 could be released quite soon though
14:29:26 tjaden it's just will be a pain if we open 4.3 early, then need to merge changes from 4.2 to 4.3 for a long time while 4.3 languishes
14:29:37 allefant true
14:29:45 tjaden so if we open 4.3, need to commit to it
14:30:14 allefant what is new in 4.2.2 btw?
14:30:18 allefant mainly the MSVC/asm stuff i guess
14:30:27 allefant looks for CVS logs
14:30:37 allefant er, SVN
14:30:39 tjaden it's quite a while since 4.2.1
14:31:07 Hitman Hi all.
14:31:21 tjaden hello
14:31:37 allefant Hitman: you are the one who is making an Amiga port?
14:32:15 Hitman Yep.
14:32:33 Hitman Actually I'm up to a stage where I could use the past tense "made."  :-)
14:32:42 allefant nice
14:32:46 tjaden cool
14:33:05 allefant and you used 4.2, but with tjaden's new events API?
14:33:35 allefant that is, 4.9
14:34:27 tjaden did you decide to work on 4.2 or 4.9?
14:35:44 Hitman I ended up working on both.
14:36:01 Hitman I started off with 4.9 (4.3.1) and yesterday I retrofitted my code to 4.2.1.
14:36:16 Hitman Allegro.jpg if you are interested.  :-)
14:36:48 tjaden cool. not too hard i hope
14:37:17 Hitman Learning the architecture of Allegro took a bit of effort and 4.3.1 is a bit more complex than 4.2.1, but other than that, no not too hard.
14:37:36 Hitman The only major thing remaining is to accelerate the graphics updating.
14:39:42 tjaden you could check it in now
14:41:09 allefant so 4.2.2 would have an Amiga port :)
14:41:40 allefant wouldn't matter if there's not as much acceleration as could be, that's expected from a new port
14:41:52 allefant and looking through the 4.2 logs since 4.2.1, definitely time for a 4.2.2
14:42:08 allefant btw, were those MSVC project files only for 4.9.x?
14:42:14 MattyMatt has quit (Read error: 110 (Connection timed out))
14:42:14 allefant i couldn't see a commit for them..
14:42:48 Hitman Well I am not sure of the best way to go about it.
14:42:53 tjaden ok, let's make 4.2.2 in a couple of weeks and open 4.3 after that
14:43:09 leverton the MSVC project files will be for 4.2
14:43:27 leverton assuming the C patches are all in there
14:44:00 Hitman Can I be guaranteed that whenever GFX_TABLE->write_bank() is called, GFX_TABLE->unwrite_bank() will be called?
14:45:25 tjaden i think write_bank could be called a few times in a row, then a single unwrite_bank
14:45:28 tjaden IIRC
14:46:08 Hitman That's right.
14:47:04 Hitman I am using unwrite_bank() to trigger redraws in my graphics rendering thread, but I need to implement some sort of locking mechanism as sometimes I get graphics screwups from the rendering thread accessing the buffer at the same time the main thread is writing to it.
14:47:54 tjaden there's a locking mechanism, but i never understood it too well
14:47:56 Hitman This could easily be done with a mutex. Claim it on write_bank() and release it (and signal a redraw) on unwrite_bank(). But in this case if someone called write_bank() but never called unwrite_bank() I would be in trouble.
14:48:23 allefant what does the rendering thread do? copy from some backbuffer to the actual videoram?
14:48:30 Hitman Exactly.
14:48:45 Hitman But that backbuffer could be being written to by the main thread at the same time, hence the need for a locking mechanism.
14:49:04 allefant yeah. the X11 port works the same way, and uses locking
14:49:05 tjaden there's vtable entries for acquire_bitmap/release_bitmap
14:49:06 Hitman Without the locking mechanism, sometimes I get part of one frame displayed and part of the next one!
14:49:41 Hitman Yes, I saw these but wasn't too sure about them and how they fit into the write_bank() and unwrite_bank() calls.
14:50:51 tjaden they should be guaranteed to be called before the first write_bank and after the last unwrite_bank, i think
14:53:20 tjaden actually, i'm not sure of that at all
14:55:11 allefant i can't find where the X11 driver does the locking
14:56:47 allefant it seems to use a global variable _xwin_in_gfx_call
14:57:02 Hitman Yeah some of the sources can be a bit complex.
14:57:15 Hitman I know the Windows version seems to do it in write_bank() and unwrite_bank()
14:57:19 Hitman So I was copying that.
14:57:23 allefant yes, X11 does as well
14:57:26 allefant but no locking in those
14:58:03 Hitman Just did some debug output and it seems that the acquire/release calls don't have any immedately noticeable relationship with write/unwrite.
14:58:53 tjaden _xwin_update_screen has _xwin_lock calls
14:59:33 allefant ahh
14:59:51 allefant i was confused by the comment over _xwin_private_update_screen claiming it is _xwin_update_screen :P
14:59:59 allefant yeah, i see now, it does locking
15:00:18 allefant so each call to unwrite_bank first locks, updates, then unlocks
15:00:52 tjaden it does sound horrible
15:01:15 Hitman I just did some tests with exhello.c where it just does a set_gfx_mode() and a readkey().
15:01:59 Hitman There are a heap of calls to write_bank() (where the screen is getting cleared) followed by one call to unwrite_bank() and then another write_bank()/unwrite_bank() pair. Not sure what the last ones are for. But no acquire/release so very curious about that.
15:02:15 allefant well, if the only access to screen is blit(buffer, screen, ...) it just calls one _xwin_update_screen() for it
15:02:27 tjaden don't worry about i said :)
15:02:42 allefant and line-by-line calls for obscuring by other windows, which looks a bit strange anyway in X11 (you can see that it does it that way :P)
15:03:11 allefant Hitman: does Amiga have OpenGL?
15:03:18 Hitman Yes.
15:03:33 allefant oh, you should try if AllegroGL works, then :)
15:03:48 Hitman Been meaning to look at it! What is it exactly?
15:04:32 allefant it provides an Allegro driver which creates a window with an OpenGL context attached
15:05:07 allefant and then implements functions using OpenGL
15:05:21 Hitman Ahh ok.
15:06:03 Hitman That might be good, because Amiga OS4 doesn't seem to support 320 x 200 (dunno why) so I was going to check with the OS devs and if it can't do it then I was going to open 640 x 480 and stretch blit the output with the gfx card.
15:07:21 tjaden shall we move on?
15:08:24 allefant hm, anything left besides the display API?
15:09:21 tjaden hmm, did matt come in?
15:09:27 tjaden mattymatt
15:09:39 leverton he got disconnected a while back
15:09:40 allefant he was there before, but his connection dropped
15:09:55 allefant oh, this reminds me, can i add him back to the SF project?
15:10:15 tjaden did he have write access?
15:10:16 allefant Eric removed him in 2004 because the PS1 branch didn't make much progress
15:10:29 tjaden ok
15:11:05 leverton are the C Only-related patches applied in the 4.2 svn ?
15:11:14 tjaden which ones?
15:11:41 leverton the ones I emailed to AD a while back
15:11:52 tjaden it's best if you check and bug me until they get applied
15:12:17 leverton I'm pretty sure you said you commited them
15:12:18 allefant mattymatt also fixed something in it recently i think
15:12:29 leverton but I'll check the 4.2 svn
15:12:59 leverton I'll be testing the MSVC project files for 4.2 today or tomorrow
15:13:36 tjaden ok
15:13:43 allefant he tried making MSVC work with asm or something i think
15:13:51 allefant but i was confused by it
15:14:10 leverton last thing he mentioned, he was super close to having it working
15:14:53 leverton that would only be useful for the 4.2 series
15:15:09 leverton at least, I think the 4.3/4.9 will basically be c-only by default
15:15:22 tjaden that was my proposal
15:15:25 allefant ah, that was the fix i meant: http://www.allegro.cc/forums/thread/591441/675936#target
15:15:42 allefant "Matt Smith: IT IS WORKING! "
15:15:48 leverton yeah
15:15:59 leverton there are some display problems with the GDI drivers
15:16:16 mimix i think he fixed that too
15:16:18 leverton they don't always refresh ... even on the asm only
15:16:28 mimix but i'm not sure
15:17:05 leverton related to the makefile stuff... if I add support for Digital Mars C compiler, does it have to support the UNIX_TOOLS environment and all the messy stuff in the MinGW makefile?
15:17:07 Hitman I am working from a tarball ATM. Is much changing on the 4.2 SVN ATM or is it mostly stable? I'd prefer to work from that.
15:17:24 tjaden 4.2 SVN is stable
15:17:47 tjaden leverton, nah
15:18:01 leverton also, what about their UNIX version?
15:18:07 leverton or Linux
15:18:10 allefant if someone wants to use DMC from msys or something, they can provide a patch..
15:18:21 tjaden they have DMC on Unix?
15:18:28 leverton maybe not
15:18:33 allefant i have dmd here
15:18:37 leverton guess I might be thinking of the D
15:18:39 allefant used it to try the D port
15:18:49 allefant as gcd didn't work yet when i tried
15:19:11 leverton DMC appears to be windows only
15:19:19 allefant hm, it's somehow a shame there's not more users of the D port, torhu did a really great job there
15:19:46 leverton I pretty much got Allegro working with dmc
15:19:50 tjaden we could make it "official" for 4.3/4.4
15:19:55 leverton it stopped at the DLL creation
15:19:55 tjaden the D bindings, i meant
15:20:01 tjaden leverton, cool
15:20:07 leverton because of wrong switches
15:20:29 leverton after I discovered the switch to relax type checking, it didn't really require many mods to the source
15:20:48 allefant tjaden: like, including in the .zip?
15:20:51 leverton the plus side of having a dmc bulid of Allegro is that you could statically link the D bindings
15:21:01 tjaden allefant, yes
15:21:12 leverton that and MinGW is messed up on Vista for now
15:21:29 tjaden ah, that would be nice indeed
15:21:31 mimix has quit (Remote closed the connection)
15:21:38 Hitman That's what I'm working on ATM. Although my port can compile for 4.3.1 I'll be releasing 4.2.1 (or 4.2.2) to the public soon.
15:21:38 Hitman Later when 4.3 is stable and released I'll switch to that.
15:22:16 tjaden i assume dmc would be easier to set up than MSVC express?
15:22:16 allefant i read on the mingw list that they will release a mingw with gcc 4.2.0 once that is out
15:22:27 allefant maybe they will also fix vista in the new release :)
15:22:50 allefant (or is just allegro-mingw broken there, not mingw itself?)
15:22:56 Hitman has quit (Remote closed the connection)
15:22:58 leverton MSVC Express is simple if you take the pre-compiled binaries ... or the new project files
15:23:20 tjaden still need the DX SDK and platform SDK
15:23:24 leverton yeah
15:23:25 mimix (i=1000@vipnet162-165.mobile.carnet.hr) has joined #allegro-dev
15:23:25 ChanServ gives voice to mimix
15:23:29 leverton you need extra files for dmc too
15:23:39 tjaden not an entire CD I hope
15:23:40 leverton the DX stuff it comes with is old or bad
15:23:56 leverton the min70 from alleg.sf seemed to work
15:23:57 Hitman (n=Colin@213-162-100-166.edenri414.adsl.metronet.co.uk) has joined #allegro-dev
15:23:57 ChanServ gives voice to Hitman
15:24:02 leverton although I didn't actually test any linking ...
15:24:39 tjaden let's go through the display API
15:25:08 tjaden or is there something else?
15:25:41 leverton I've got nothing else
15:26:56 tjaden can elias and trent lead us here?
15:27:18 allefant well, should we go through the functions in Bob's API? http://wiki.allegro.cc/NewAPI/Documents/gfx-api
15:27:33 tjaden yup
15:27:37 leverton should we comment on the Display API first ?
15:27:46 leverton it's small ;)
15:27:51 tjaden ok
15:27:55 amarillion (n=martijn@82-170-26-59.dsl.ip.12move.nl) has joined #allegro-dev
15:27:55 ChanServ gives voice to amarillion
15:28:06 leverton I looked at it briefly before, because I was going to do a D3D driver
15:28:20 leverton but I'm happy that trent is working on one , because I know nothing about it...
15:28:27 allefant heh
15:28:31 leverton anyway, I was wondering first about the create_display
15:28:35 trentg How will we select the render target?
15:28:50 leverton it seems that color depth should be it's own parameter
15:28:58 leverton esp if we have all those things that Bob was proposing
15:29:23 allefant in Bob's it looks like this: AL_DISPLAY *al_create_display_bitmap(al_id_t card, int width, int height, al_id_t format, al_id_t update_method)
15:29:31 trentg I think we should use pixel formats instead of color depths.
15:29:56 allefant i was somehow scared of all the params, as myself, i usually only want to specify at most width and height
15:31:08 trentg What do you think of al_create_display(flags, format, w, h)?
15:31:34 leverton would format be one of AL_COLOR_5_6_5 , etc?
15:32:08 trentg Something like that, yes. Where is that defined?
15:32:10 leverton bob also had things like AL_RGBA vs AL_YUV
15:32:17 leverton it's in Bob's API
15:32:30 allefant search for "al_create_display_bitmap"
15:32:43 leverton I just saw everything that Bob had proposed and wondered if we'd end up with a million different flags in one param
15:32:44 allefant the comment has a list of some formats
15:33:16 allefant we could have something like: al_set_display_format(al_id_t card, al_id_t format, al_id_t update_method)
15:33:22 allefant which would be strictly optional
15:33:27 Hitman Make sure you keep that _rgb_r_shift_15 etc. variables. These are really handy for systems that can work in big or little endian mode (like the Amiga)!
15:33:39 allefant the next call to al_create_display then would take them as a hint
15:34:00 leverton hmm
15:34:01 allefant (if the driver has no support, either ignore them or raise an error)
15:34:05 trentg I'd rather see a single parameter, like R8G8B8A8 or something.
15:34:28 leverton I suppose the split works for multiple windows
15:34:55 leverton that is , if you want multiple windows, the set_display_format would probably be teh same
15:35:04 leverton for both windows
15:35:08 allefant yeah
15:35:11 trentg I like that, allefant.
15:35:16 allefant it could be different of course
15:35:22 leverton yeah
15:35:45 allefant like, you have one window where you let allegro select everything, then let the user specify stuff in there for the main window
15:36:34 trentg So update method is still just a hint?
15:36:38 allefant but basically, we wouldn't have people write set_gfx_mode(GFX_DIRECTX, ) and i have to change the code when i want to run it here :)
15:36:47 leverton with the extra call, so would create_display just be width and height ?
15:38:04 trentg I guess so.
15:38:28 trentg I'm still a bit confused about setting the target bitmap/display.
15:38:48 allefant normally, you shouldn't need either
15:38:50 tjaden it was in the first log
15:39:00 allefant the target display is needed only if you use multiple windows
15:39:23 allefant then if you want to start drawing to another window, you use l_change_current_display
15:39:23 trentg So will AL_DISPLAY be an AL_BITMAP?
15:39:29 tjaden no
15:39:57 allefant the target bitmap is needed if you draw somewhere else than the screen
15:40:12 trentg Then how do you set it back to the screen?
15:40:13 allefant so most likely, a memory or off-screen bitmap
15:40:36 allefant al_get_backbuffer()
15:40:50 allefant hm, which is a bit ugly
15:40:59 allefant maybe if you pass NULL?
15:41:02 mimix drawing to a off-screen bitmap is not a very uncommon operation tho
15:41:24 allefant yeah
15:41:42 leverton yeah, I was wondering about: al_line(0, 0, 100, 100, red)
15:41:50 allefant opengl does it like that
15:41:51 leverton does that imply you can only draw to back buffers?
15:42:19 allefant to draw to a bitmap you would do:
15:42:28 allefant al_select_target_bitmap(bmp);
15:42:34 allefant al_line(0, 0, 100, 100, red)
15:42:43 allefant al_select_target_bitmap(al_get_backbuffer())
15:42:50 allefant al_draw_image(0, 0, bmp)
15:42:53 trentg I vote for using NULL to render to the current display.
15:43:06 allefant the last 2 lines to then render the bitmap to the screen
15:43:19 leverton ok
15:43:24 leverton that makes more sense
15:43:34 leverton what about when you have multiple back buffers?
15:43:40 leverton what does al_get_backbuffer() do?
15:43:59 leverton if that makes any sense
15:44:10 allefant my idea was, it returns a special AL_BITMAP, which always references the correct one
15:44:26 tjaden the "next" one, i guess
15:44:41 allefant yes, e.g. if internally the gfx driver uses page flipping
15:45:04 leverton well, I suppose there would never need to be more than 2 back buffers
15:45:24 allefant at least, you wouldn't need to directly access them
15:45:29 leverton yeah
15:46:03 allefant i don't know if al_get_frontbuffer() is generally supported
15:46:10 allefant but KittyCat suggested it
15:46:27 allefant no idea what it would be e.g. in OpenGL().. but in classic page flipping, it would be the currently visible page
15:46:33 leverton does that have any significance for single bufering system?
15:46:43 peterhull (n=peterhul@cpc2-wilm1-0-0-cust169.bagu.cable.ntl.com) has joined #allegro-dev
15:46:43 ChanServ gives voice to peterhull
15:46:52 allefant no, with a single buffer, al_get_backbuffer() would be that buffer
15:46:53 peterhull (n=peterhul@cpc2-wilm1-0-0-cust169.bagu.cable.ntl.com) has left #allegro-dev
15:47:11 allefant and al_get_frontbuffer() should most likely return NULL
15:47:25 allefant as there is no way to directly update before the next al_flip()
15:47:45 allefant or al_flip_display()
15:48:14 tjaden well, writing to the "backbuffer" would be a direct update
15:48:32 allefant ah, well
15:48:40 allefant in my terminology, that would be completely unbuffed
15:49:07 allefant hm
15:49:11 allefant but yeah
15:49:18 leverton so if you had multiple displays... does al_change_current_display() call al_select_target_bitmap(al_get_backbuffer()) automatically?
15:50:00 mimix i say no
15:50:01 allefant i just made "single buffering" and "double buffering" be the same :P
15:50:07 trentg I don't think you can actually render to the front buffer, unless it's the only one.. you can just read pixels directly.
15:50:54 tjaden i think no as well, e.g. what if a memory bitmap was the current target
15:51:17 leverton and what does al_change_current_display() affect?
15:51:33 leverton other than get_backbuffer ?
15:51:39 tjaden thread local variables
15:51:44 tjaden change GL context
15:51:59 allefant it affects to which window the following graphics commands are directed
15:52:24 leverton but doesn't the target bitmap do that?
15:52:58 allefant it could be made to, most likely
15:53:30 allefant if each AL_BITMAP has an AL_DISPLAY pointer, and selecting a bitmap automatically "changes the display" if it is not the current one
15:54:02 allefant but since al_change_current_display() will be very rarly used, i didn't see this as a big advantage
15:54:06 leverton yeah
15:54:09 trentg Should each bitmap be tied to a single display though?
15:54:50 leverton displays could be different color depths etc, if that has any relevance
15:55:17 allefant yeah, or if each window has its own OpenGL context, i don't think they share textures by default
15:55:24 trentg You should still be able to draw one bitmap to any display.
15:55:33 allefant so would definitely be the most simple solution, implementation-wise
15:55:39 allefant only a memory bitmap
15:55:58 allefant normal bitmaps are tied to their display
15:56:13 allefant that's also like that in Bob's API I think
15:56:38 trentg OK, I have them so they can be drawn to any display, but I can change that.
15:56:57 allefant AL_BITMAP *al_create_bitmap(int flags, AL_DISPLAY *inherit_from, int width, int height);
15:57:12 allefant the inherit_from parameter would be the currently selected display
15:58:39 leverton from Bob's doc: The inherit_from parameter is required for creating video or system bitmaps.
15:58:53 leverton so does that param have any meaning to a memory bitmap?
15:58:59 allefant from Bob's blit docs:
15:59:02 allefant "* Additionally, you may not blit from a video, system, display, or sub-bitmaps
15:59:02 allefant * thereof that inherit from one display bitmap to video, system, display or
15:59:02 allefant * sub-bitmaps thereof that inherit from some other display bitmap.
15:59:02 allefant * That is, video and system bitmaps are linked to the display bitmap they
15:59:02 allefant * inherit from, and cannot be directly blitted to some other display bitmap
15:59:02 allefant * or associated video and system bitmaps. If you really need to cross-blit
15:59:02 allefant * in between display bitmap 'families', then use a temporary memory bitmap."
15:59:37 leverton I think that limitation makes sense from an implementation standpoint
16:00:10 allefant we could trivially lift the limitation by just creating the temporary memory bitmap for the user..
16:00:22 leverton but I was just going to say that might not be a good idea
16:00:28 leverton if it is bad for performance
16:00:29 allefant and if e.g. D3D allows blitting the same texture to multiple windows, it could implement that
16:00:41 allefant yeah, it certainly is bad for performance
16:00:49 allefant (the memory bitmap)
16:01:19 allefant but then, there might be a way to do it in a better way with OpenGL as well
16:01:39 leverton well I'm cleared up on the basics now
16:01:42 allefant i don't really have any experience with multiple windows and OpenGL.. but my idea was to upload a bitmap to both
16:01:45 mimix aren't we supposed to make the used unaware where the bitmaps resides, by default?
16:01:54 mimix *user
16:02:12 leverton * Flags can be only one of:
16:02:12 leverton * - AL_BITMAP_TYPE_MEMORY == 0
16:02:12 leverton * - AL_BITMAP_TYPE_VIDEO
16:02:12 leverton * - AL_BITMAP_TYPE_SYSTEM
16:02:17 allefant yes, but they can specifically ask for a memory bitmap (aka device independent)
16:02:24 leverton that is a param to create_bitmap
16:02:38 mimix we need another flag then
16:02:39 trentg What's the difference between system and video?
16:02:45 allefant i think we don't need the VIDEO and SYSTEM any longer
16:03:12 tjaden i think the gfx api came before the idea that bitmaps should shift around automatically
16:03:13 trentg Just VIDEO then?
16:03:32 allefant just MEMORY
16:03:55 allefant or else by default the driver decides (D3D and OpenGL would try to upload as texture)
16:04:32 leverton so does the programmer know if create_bitmap returns a memory bitmap or not?
16:05:05 leverton I'm asking because it would then matter if there was a limitation between blitting between different displays
16:05:59 tjaden the user needs to know
16:06:02 mimix AL_BITMAP_TYPE_AUTO, should do all automagically
16:06:40 kazzmir (n=kazzmir@c-71-192-58-236.hsd1.ma.comcast.net) has joined #allegro-dev
16:06:40 ChanServ gives voice to kazzmir
16:06:43 allefant the problem is, assume the user opens two windows, loads a number of bitmaps, and wants to draw them to both windows
16:07:00 allefant if they can't be shared, then they basically need all be duplicated
16:07:02 mimix the user should specify AL_BITMAP_TYPE_MEMORY explicitly if he cares about performance and wants to blit onto multiple windows
16:07:13 mimix from what i read in glXCreateContext manpage, textures can be shared between multiple contexts
16:07:26 mimix the 3rd param
16:07:32 allefant yeah, so likely we could be nice and allow having them shared :)
16:08:22 trentg Would avoid a lot of confusion I think.
16:08:22 allefant so i could do: mysprite = al_load_bitmap("sprite.png"); and then draw it in multiple windows
16:09:32 mimix with AL_BITMAP_TYPE_AUTO allegro can take care of it
16:09:36 allefant but if the driver can't suppot it, it's bad
16:09:49 tjaden i'm not convinced we can implement the AUTO stuff
16:09:59 mimix me either :)
16:10:16 tjaden it sounds too much like magic
16:10:35 tjaden and heuristics everywhere
16:10:39 allefant of course, we could get crazy, and allow having in each AL_BITMAP a list of textures (one for each AL_DISPLAY it is drawn to)
16:10:42 leverton what's the harm in making the programmer specify video vs memory ?
16:10:46 mimix user who know what they are doing won't use AUTO
16:11:20 mimix video bitmaps will be slow on some drivers
16:11:33 trentg The only problem is if you have a lot of bitmaps, you don't want to have two copies of every one if possible.
16:11:53 trentg Or really? I thought memory would be slower.
16:11:56 MattyMatt (i=MattyMat@cpc4-birk4-0-0-cust613.bagu.cable.ntl.com) has joined #allegro-dev
16:11:56 ChanServ gives voice to MattyMatt
16:12:21 mimix if the driver doesn't support real video bitmaps
16:12:31 mimix like X11
16:12:41 allefant the 4.2 X11 "video bitmaps" are stupid
16:12:49 allefant we wouldn't do something like that in 4.9 drivers
16:13:40 allefant they just are sub-bitmaps of screen, if you create a screen bitmap bigger than the actual window
16:14:00 trentg How hard is it to share textures with OpenGL?
16:14:00 allefant they only were done to simulate page flipping i think
16:14:19 mimix having a list of AL_DISPLAYs per AL_BITMAP is not such a bed idea
16:14:33 trentg That could be driver dependant.
16:14:33 mimix maybe some contexts will allow shareing and some won't
16:14:50 tjaden if you write to one the rest must be invalidated
16:14:51 mimix beause of some color cnmopability isseus
16:14:53 allefant yeah, a driver who can share the AL_BITMAP would do so. one who can't could create a texture upon first use
16:15:26 allefant yeah, writing to bitmap's is another issue
16:15:37 allefant first, there's just writing to it, vs. direct pixel access
16:16:10 trentg Yeah.. I only have rendering to a texture now, but that probably isn't supported on all cards.
16:16:41 allefant if it's not supported (same as OpenGL with no FBO support), the only way is a memory buffer
16:16:58 trentg And use Allegro's software functions?
16:17:23 allefant yeah
16:17:39 allefant (in theory, could do some hack to draw to the screen and copy back.. but i don't think it realyl would work out)
16:17:53 mimix what sbout video bitmap's internal memory copy?
16:18:00 mimix Bob's API makes it optional
16:18:23 mimix some functions are a pain to implements without it
16:18:36 trentg I think it's needed if you want to render directly to the texture.
16:18:48 allefant does directx still lose VRAM contents from time to time?
16:18:55 trentg Yes.
16:19:02 allefant then we need it in any case i'd say
16:19:18 trentg I agree.
16:19:54 MattyMatt unless you declare it as unneeded
16:20:02 allefant yes, we should have a way to do that
16:20:51 allefant so if you know you don't need to keep the memory copy in sync, the driver could do that in a lazy way
16:20:52 MattyMatt e.g. intermediate output buffers used for FSAA or sth
16:20:54 trentg The program will crash, at least in D3D if you don't re-upload the data after it's lost.
16:21:02 mimix i could find a way to implement even a video bitmap getpixel() without memory copy and FBO
16:21:24 mimix ... in AGL
16:21:29 allefant could or couldn't?
16:21:41 mimix oh, couldn't
16:22:07 mimix i'm not saying it's impossible
16:22:22 allefant but is there a way to copy back from the FBO to memory?
16:22:38 mimix yes
16:22:46 mimix but what if there is no FBO
16:22:51 trentg We can always make that a flag to al_load_bitmap and al_create_bitmap, that is taken as a hint in case it's not possible.
16:22:53 allefant so like, if you draw a lot of stuff, then do one getpixel, instead of copying everything in memory, it could update the memory version once
16:23:24 allefant without FBO, you can still read back the texture
16:23:31 mimix how?
16:23:51 allefant some glGet...
16:24:39 allefant glGetTexImage
16:25:02 mimix good to know
16:26:16 leverton will there be al_resize_display() ?
16:26:42 MattyMatt I should hope so :)
16:26:44 tjaden i think yes
16:26:52 allefant i should add it
16:26:58 allefant even have it implemented in X11
16:27:07 MattyMatt and GDI
16:27:13 tjaden i just added al_destroy_display to the wiki page. what do we do with bitmaps tied to the display?
16:27:32 MattyMatt lose them
16:27:37 allefant i say no
16:27:43 allefant the tie should be one way
16:27:58 tjaden so what happens to them?
16:28:25 tjaden it's a user error?
16:28:28 allefant actually, it probably depends on the previous question
16:28:53 allefant if we allow an AL_BITMAP to be drawn to multiple AL_DISPLAYs, destroying one display can't destroy the bitmaps
16:29:33 tjaden it's still possible
16:31:09 allefant given that multiple windows aren't that useful, it really makes things complicated
16:31:12 MattyMatt I thought screen and video bitmaps would be the only bitmaps tied to an AL_DISPLAY
16:31:36 MattyMatt that's so wrong. lots of people are screaming for multiple windows
16:31:42 allefant ok, good to know then :)
16:31:44 MattyMatt including me
16:32:03 MattyMatt multiple windows also means multiple screens
16:32:32 mimix ouch, i think the user might need to specify in al_create_bitmap a list of AL_DISPLAYs for the AL_BITMAP to be compatile with
16:32:42 allefant my scenario now looks like this: the user loads a bunch of bitmaps, opens 2 windows, and the driver allows sharing them
16:33:00 allefant now if one dispaly is destroyed, neither the bitmaps not even their uploaded textures should get invalidated
16:33:15 allefant if the second dispaly is destroyed, all textures are invalidated
16:33:22 allefant not sure about the actual AL_BITMAPs
16:33:46 tjaden well, in those cases the bitmaps weren't tied to the displays
16:33:48 MattyMatt yeah but if the windows use different drivers (very possible if one is an overlay) then that means 3 copies
16:34:51 MattyMatt so, only the memory bitmap should be untouchable, and be considered the master
16:35:30 MattyMatt then if an AL_DISPLAY keeps its own copy, it should handle updating it from the master
16:35:49 allefant so i see now, we actually have 3 types of bitmaps
16:36:00 allefant MEMORY, SHARED, and tied to a single display
16:36:25 allefant the SHARED would e.g. by glx textures who can be drawn to multiple windows
16:37:50 MattyMatt sound right
16:38:10 tjaden how about this? i create a bitmap, initially MEMORY. then using a function call i mark the bitmap so it is blittable to a particular window (or more than one) fast, becoming SHARED. (contd)
16:38:32 MattyMatt the directx driver currently keeps a couple of private surfaces anyway
16:38:45 tjaden if i update the bitmap, i must call the function again which essentially reuploads the texture
16:39:41 tjaden so instead of this bitmap migration being automatic, it's up to the user. later we can try to make it automatic
16:39:58 allefant only problem is, how to make use of FBOs then
16:40:00 MattyMatt or it could be automatic, but that mean using the dirty_lines[] technique even on memory bitmaps
16:40:13 leverton personally, I'm in favor of forcing the user to provide hints
16:40:13 allefant i.e. it directly draws to the texture, not the memory bitmap
16:41:35 tjaden i think it would still work in the general scheme
16:42:04 MattyMatt yeah, extra params to create_bitmap()
16:42:10 tjaden read MEMORY as 'master copy' or something
16:42:17 allefant yes
16:42:31 tjaden updates to the master don't necessarily propagate unless the user asks for it
16:42:41 allefant and as we said before, a flag AL_BITMAP_NO_SYNC, so it wouldn't try to keep the memory copy up-to-date
16:43:01 allefant and instead do render-to-texture if supported
16:43:26 tjaden we have to get this all written down so it doesn't keep being reinvented
16:43:32 MattyMatt that's the other way round, but is also important. 2 flags then
16:43:55 MattyMatt it is written down in the logs here :)
16:44:19 MattyMatt I fell asleep and got disconnected tho :p I've got a 2hr gap
16:44:35 allefant heh
16:46:50 MattyMatt the directx code needs rearranging internally anyway, because there's nowhere "proper" to keep window state info. I could use the AL_DISPLAY analogy for that
16:47:23 tjaden so who has a clear idea how bitmaps work now? i don't
16:47:34 trentg Not entirely.
16:47:38 allefant i have a clear idea what i want in the single-window case
16:47:52 allefant sprite = al_load_bitmap("sprite.png"); should upload to a texture of the current display
16:48:07 allefant al_draw_bitmap(0, 0, sprite); draw the textured, HW accelerated
16:48:09 allefant :)
16:49:22 leverton isn't it easiest if we just originally force the user to provide hints for all of these questionable topics?
16:49:32 leverton and as the drivers mature, make decisions on what can be automated?
16:49:46 allefant that would be the 4.2 way, create_video_bitmap
16:49:58 allefant to explicitly manage textures. so my example wouldn't work
16:50:26 mimix i don't think we have to dramaticaly change the API for A5, it still has to be allegro
16:50:27 MattyMatt al_bitmaps_create_as(AL_VIDEO);
16:50:33 Hitman has quit ("I love jahc")
16:51:05 MattyMatt then all create_bitmap() or load_bitmap() after that are affected
16:51:23 trentg I like the idea of having a flag, like al_load_bitmap("sprite.png", VIDEO), and the rest is handled transparently.
16:51:47 tjaden the transparently part is the hard part
16:51:50 trentg And the flag is taken as a hint.
16:52:05 trentg Yeah, maybe.
16:52:18 tjaden well, i assume. if you guys writing the code think it's ok..
16:52:22 allefant yeah, it's easy to make the API simple, and then the implementation very hard
16:53:04 MattyMatt there could be user defined types of bitmap too, e.g. type = al_create_bitmap_type("TILE",..hints); al_load_bitmap("sprite.png", type);
16:53:36 leverton my biggest concern as a user is that some of the transparently handled things could negatively affect performance without me realizing it
16:53:52 MattyMatt allefant, that's generally a good thing :) to hide as much complexity as possible internally
16:54:42 trentg Well, I don't know much of how OpenGL works, so it's hard for me to say what is a good way to do it.
16:55:03 allefant i believe what works in D3D should work there as well
16:55:23 tjaden i think we need more implementation experience. if it turns out to be too hard, change the API
16:55:34 leverton yeah
16:55:54 trentg Yeah. We'll never figure it all out today :)
16:55:59 MattyMatt yep code first, doc later. that's my new catchphrase :)
16:56:34 trentg But it would be good to have a starting point..
16:56:49 trentg Something to work towards.
16:56:54 allefant let's just defer the question about multiple windows for now, then
16:57:00 tjaden which brings us to decide a minimal core gfx API
16:57:55 trentg First off, multiple clipping rectangles may be very difficult to implement.
16:58:02 tjaden we're dropping that
16:58:06 allefant agreed
16:58:15 MattyMatt yeah
16:58:19 tjaden i think we decided that in the first log
16:58:26 allefant :)
16:58:40 allefant what about masking?
16:58:51 allefant D3D and OpenGL both will have a hard time with it, from what i gather
16:59:06 trentg I've got masking all done in D3D, but it's not easy or fast.
16:59:13 allefant but magic pink is one of the core features of 4.2.. so at least the compatibility layer has to support it
16:59:38 tjaden so it's usually done with a alpha channel?
17:00:02 trentg Yeah. It can be done with a stencil buffer but that's slower. I had to use stencil for rotated & DEST_MASK though.
17:00:18 MattyMatt some 4.2 funcs respect bitmap->vtable->mask_color, some don't
17:00:43 allefant no point fixing 4.2 there
17:01:07 allefant i don't think anybody will assume something besides magenta works
17:01:11 trentg But even using the stencil, you still need alpha.
17:01:14 MattyMatt I think a blit from masked to alpha would suffice
17:01:36 allefant yes. so on loading, you could convert the mask to an alpha channel
17:01:59 allefant although these days, i find it easier to output an alpha channel than a mask, from graphics programs
17:02:00 tjaden for the compat layer, we can use RGBA images and if a magic pink pixel gets written update the alpha channel as well
17:03:04 trentg What if they want it blended?
17:03:15 MattyMatt hints
17:03:41 MattyMatt stateful hints so the user code isn't littered with them
17:04:11 trentg I think we could have a al_check_bitmap_flags() function that checks which flags are supported by the driver.
17:04:22 trentg Which combinations and stuff.
17:04:36 allefant so basically, keep support for masking
17:04:36 MattyMatt and so they can be implemented by hacking the vtables without affecting performance of every draw op
17:04:54 tjaden it seems pretty important
17:05:14 MattyMatt yeah. sprite fans need masking
17:05:21 allefant well, that the D3D driver as well as AllegroGL already support it is a strong point for it
17:05:32 allefant just in both cases alpha channel performs much better
17:05:53 trentg Yes, well the user will be encouraged to use the alpha channel :)
17:05:54 MattyMatt so the slow way is what you get if you fail to hint properly
17:06:56 allefant hm, about the flags in Bob's al_blit()
17:07:25 allefant should something like masking or AL_BLEND not be a permanent bitmap flag?
17:08:11 trentg It would potentially speed things up if it was.
17:08:46 allefant so maybe: al_set_bitmap_flags(AL_BITMAP *bitmap, int flags)
17:08:51 MattyMatt I haven't looked at the fine details of the flags, but extra flags don't do any harm. 32 bits in an int
17:08:58 trentg but could DEST masking be a permanent flag?
17:09:02 allefant and you could pass AL_MASK_SOURCE, AL_BLIT
17:09:08 allefant just was wondering about that
17:09:18 allefant destination masking isn't supported in Allegro 4.2
17:09:34 tjaden i think bob said we should remove that at some stage
17:09:50 trentg It was the hardest part to implement.
17:10:00 trentg And the slowest.
17:10:07 tjaden but you did it?
17:10:11 trentg Yes.
17:10:25 allefant so it would force us to also do it for opengl, if it stays :P
17:10:39 trentg I can see some neat effects coming out of it, but I'm not sure it's worth it.
17:11:14 trentg Well like I said, if we had a function to check the drivers capabilities, you wouldn't have to.
17:11:17 MattyMatt if it doesn't cause bloat, then it's worth having, IMO
17:11:36 trentg It's only an extra hundred or two lines.
17:11:49 MattyMatt even if a feature only performs well on one platform, that's justification enough
17:12:25 allefant my idea was to use opengl directly for such things, using glBlendFunc and glLogicOp
17:12:28 trentg I'd like to keep it now that it's done. And in the end it wasn't all that hard.
17:12:40 allefant but then, the AL_OPENGL flag won't work in the D3D driver
17:13:29 MattyMatt do all GL implementations start texture handles at low numbers?
17:13:43 allefant likely
17:13:55 allefant the standard doesn't require it though
17:14:06 allefant so if it starts with 1000 instead of 1 you should be prepared for it
17:14:06 MattyMatt numbers that could be used directly as indices to an array
17:14:42 MattyMatt yeah it's a bad idea what I'm thinking
17:16:01 allefant how did you implement destination masking?
17:16:05 MattyMatt which was keep an array of structs which hold things like pointer to memory master, pointer to DX surface etc
17:16:42 trentg I created a texture on the fly that had alpha in the spots where there's mask color in the destination buffer.
17:16:56 trentg If it's rotated any, i used the stencil buffer.
17:17:08 allefant and then delete the texture at the end of al_blit again?
17:17:14 trentg Yeah
17:17:44 allefant hm, i'd like to say no to that..
17:17:54 allefant seems unlikely there will be any HW supporting it in a cleaner way
17:18:42 trentg Yeah. It could be kept, but it will never be very fast.
17:18:47 MattyMatt although if the mask is automagically turned to alpha, then GL supports dest alpha
17:18:50 allefant we could have an extra lib with various special effects, wrapping on top of OpenGL and D3D, at one point
17:19:24 allefant that could then have destination masking, different blend functions, logic ops, and so on..
17:19:39 allefant so you could draw s sprite flashing to white with a red outline
17:20:05 trentg I'm open to it. I'm not in love with destination masking or inverse source masking.
17:20:45 allefant so let's stay with support for masking, as it's needed for the compatibility layer and is quite popular
17:20:46 tjaden what would inv src masking be good for?
17:21:09 trentg Not much.
17:21:18 allefant we would need Bob here, he could explain why inv_src and dest masking was in
17:21:22 MattyMatt making alpha masks
17:21:35 MattyMatt prolly there just because GL has them
17:21:45 MattyMatt on a completely different subject, are vertex arrays supported in D3D in a compatable way with GL?
17:22:02 trentg I'm not sure.
17:22:36 allefant so, AL_MASK_DEST, AL_MASK_INV_SOURCE, AL_MASK_INV_DEST can go
17:22:48 trentg OK.
17:22:51 allefant and AL_MASK_SOURCE and AL_BLEND would be a property of the bitmap itself
17:23:01 allefant stored in AL_BITMAP.flags or so
17:23:12 MattyMatt sounds good
17:23:20 trentg Will mask color be able to be changed after it's set?
17:23:44 MattyMatt if possible. I have heard requests for this
17:23:51 allefant yes, i was thinking of: al_set_bitmap_mask_color(AL_BITMAP *, AL_COLOR)
17:24:14 allefant i just see, Bob only has an al_get_bitmap_mask_color
17:25:07 allefant we could al_get_bitmap_mask_color to return a different color
17:25:10 allefant *allow
17:25:27 allefant so the driver is free to modify pixels when you change the mask color for a bitmap
17:25:31 MattyMatt yeah, every bitmap should have its own mask_color. dunno how this would deal with RGBA tho
17:26:08 allefant trentg: can AL_MASK and AL_BLEND be combined in your impelmentation?
17:26:17 trentg Yes
17:26:33 allefant we should allow it then i guess
17:26:46 MattyMatt maybe is_getpixel_masked(bmp, x, y) could return true if alpha==0
17:26:49 trentg I may be changing my implementation though, to go with these new changes.
17:27:28 allefant well, i don't see the point of having an alpha channel plus a mask color
17:27:30 trentg I would like to have set_mask_color change all masked pixels to alpha.
17:27:53 trentg Ahead of time.
17:28:05 trentg But then there's no way to change back.
17:28:19 MattyMatt what about the old mask color? change all them too?
17:28:31 allefant hm, that's why i was thinking of having no masking at all
17:28:49 allefant since it would be rather trivial to convert to alpha beforehand
17:28:55 trentg Well, mask color could be set once and that be final.
17:29:23 trentg or name it al_mask_bitmap
17:29:45 allefant or al_compat_mask_bitmap :)
17:29:50 MattyMatt that could be one behaviour. the user might prefer to have control over masking, rather than gain the performance of alpha
17:29:51 allefant and only use in the compatibility layer..
17:30:49 trentg Yeah. I see no harm in having it as a function of the new api too, though.
17:31:13 allefant yes. if it's in the vtable, it should be exposed
17:31:38 trentg I like that idea. That should give good performance.
17:31:55 allefant but then, we didn't want to model the new API just for the sake of the compatibility layer
17:32:22 trentg Well, some people will still want to use masking, this gives them an option.
17:32:25 allefant and it seems, converting to an alpha channel normally is a better solution than "run-time masking"
17:32:46 trentg Yes.
17:33:03 allefant do you also need an intermediate texture for that btw?
17:33:03 MattyMatt this is another argument for user defined types. The user might want to create a class of bitmaps that uses an unusual set of hints, and so has a custom vtable
17:33:14 trentg Yeah, for run time masking.
17:33:53 trentg Direct3D doesn't have all the extensions GL does.
17:34:19 allefant and in GL, it just means there needs to be a fallback implementation in addition to the extended ones
17:34:48 trentg Yeah. I think writing it to fit the hardware is better.
17:35:09 trentg So, I think the masking flags should all go.
17:35:22 allefant yeah
17:35:39 allefant and name the function: al_convert_mask_to_alpha(AL_BITMAP *bmp, AL_COLOR mask)
17:36:29 trentg I like it.
17:37:10 allefant ok
17:37:29 allefant so the remaining flags to al_blit are: AL_LIT, AL_HORIZONTAL_FLIP, AL_VERTICAL_FLIP
17:37:54 allefant i'm not really sure what AL_LIT does
17:37:58 trentg what about BLEND?
17:38:14 trentg LIT is like draw_lit_sprite
17:38:31 allefant oh
17:38:42 allefant i thought BLEND just tells if alpha is to be used or not
17:38:53 allefant but there is also al_set_blender..
17:38:54 allefant hm
17:38:56 trentg Yeah, it does.
17:39:06 trentg That's what I thought too.
17:39:19 allefant for using the alpha, it should be a flag of the AL_BITMAP
17:40:35 trentg What should BLEND and LIT do then?
17:40:49 allefant i don't find the al_set_blender specification
17:41:11 allefant did Bob forget it?
17:41:16 MattyMatt is LIT somthing to do with additive blending?
17:41:28 trentg LIT tints to a color.
17:41:36 allefant * - AL_LIT - Lits the source pixels with the current blend color
17:41:36 allefant * before writting them to the destination.
17:41:36 allefant * This flag cannot be used with AL_BLEND.
17:41:46 allefant but tints in what way?
17:42:13 allefant there seems to be no function to modify the blend color as well
17:42:20 trentg Alpha defines the intensity. So 0xFF alpha makes it a solid tint-color.
17:42:21 allefant but e.g. assuming the blend color is white
17:42:29 allefant what does AL_LIT do?
17:42:44 allefant make the bitmap 50% "lit" to white?
17:43:07 trentg AL_LIT with 0xFFFF0000 would make the bitmap completely red, 0xFF7F0000 would make it 50% red
17:43:22 trentg At least that's what it's like in Allegro currently.
17:43:38 mimix in 4.2 it uses set_trans_blender i think
17:43:48 mimix or any other blendser you select
17:43:52 amarillion has quit ("Leaving")
17:45:23 trentg oops, i meant 0x7FFF0000 would make it 50% red
17:46:08 trentg So should we have another flag, AL_ALPHABLEND?
17:46:24 allefant well, first, we need to find out what al_set_blender would have looked like
17:46:39 allefant maybe the LIT and BLEND can be combined to one flag
17:46:47 allefant as Bob disallows using them together anyway..
17:47:26 MattyMatt again I say, extra flags are harmless
17:47:34 trentg I guess al_set_blender would say what type of blending to use. e.g. addititive, subtractive, etc.
17:47:45 allefant and what would it affect?
17:47:46 trentg I don't think LIT and BLEND can be combined.
17:47:53 MattyMatt better to have too many in the first implementation than too few
17:47:56 allefant all subsequent calls to al_blit for the same display?
17:48:11 trentg Only calls using AL_BLEND
17:48:21 allefant ah, of course
17:49:24 trentg So we could have an alpha blender that you can set with al_set_blend
17:49:24 allefant ok, well, apparently, this is incomplete.. the possible parameters for both would be the same as in 4.2, i assume
17:52:33 allefant ok, we need a proposal of a good set blend/lit flags
17:52:37 allefant *of
17:52:50 trentg lit is easy. It's just a color.
17:53:26 trentg For blend, we should take a look at what types of blending OpenGL and Direct3D both offer.
17:54:01 tjaden i'm going to go to sleep. i'll read the logs tomorrow
17:54:12 tjaden has quit ("cya")
17:54:24 MattyMatt yeah, the flags should be negotiated between whoever implements the dx and gl drivers
17:54:50 trentg I have a question about the compatibility layer.
17:56:29 trentg Should we be implementing a full GFX_DRIVER?
17:57:00 MattyMatt no need, just the user funcs
17:57:20 allefant yes, the idea was to just have a set of wrapper functions, calling 4.9 functions
17:57:38 trentg My idea was to just have the screen updated after each drawing operation to the screen.
17:57:42 MattyMatt GFX_DRIVER will largely be replaced by AL_DISPLAY, afaics
17:58:00 allefant trentg: for now, i guess that is a good idea
17:58:20 MattyMatt the dirty_lines[] takes care of that in windows, atm
17:58:21 trentg It makes it a lot easier, and we can focus on the new API.
17:58:25 allefant yeah
17:58:58 allefant it means, old and new API can't be mixed, but that should be no problem
17:59:14 trentg Yeah. That's OK I think.
17:59:14 allefant or actually, they can
17:59:26 allefant you can always use the old API to draw to bitmaps
17:59:45 trentg But they're BITMAP's not AL_BITMAP's.
18:01:08 allefant yep
18:01:23 MattyMatt i thought they were synonyms
18:01:26 allefant but you can draw a BITMAP to the new screen
18:01:30 allefant not now
18:01:45 allefant once 4.9 API is complete, they might become synonyms
18:01:53 MattyMatt cool
18:01:57 allefant but we need a way to implement it all first..
18:02:14 allefant it's what got me halted in my attemps
18:02:16 MattyMatt I thought that was a major reason for prefixing the new API at all was to lose BITMAP :)
18:02:23 trentg So we're going to allow mixing old and new api calls? Sounds confusing.
18:02:49 allefant no, i just meant.. right now, it should work
18:03:19 trentg How would it? BITMAP and AL_BITMAP don't have anything in common.
18:04:04 allefant i was thinking you could use 4.2 functions to draw to BITMAP, then have one special temporary function, which blits a BITMAP to an AL_BITMAP
18:04:43 trentg I kinda have that now.
18:05:07 trentg I have a vtable hook call upload_compat_bitmap, that I use for the screen whenever it changes.
18:05:18 allefant i must do that as well
18:05:37 allefant i made load_bitmap work in a similar way already i think
18:06:15 trentg At first I had it doing that for all bitmaps, then I realized only the screen needs it.
18:08:10 MattyMatt I would offer to start a GDI sofware only version of the API, but I need to get a job pretty soon
18:08:20 leverton has quit (Read error: 110 (Connection timed out))
18:08:51 MattyMatt hopefully one that leaves me a bit of time :) coding jobs tend not to tho
18:09:48 allefant ok, about LIT/BLEND, maybe we can just copy the OpenGL specification there
18:10:21 trentg What does it say about LIT?
18:10:48 allefant well, in allegro 4.2, LIT can be additive/multiplicative and so on
18:11:12 allefant so if i understand right, it is the same as OpenGL's constant color in glBlend
18:12:02 trentg So should we combine LIT and BLEND then?
18:12:07 MattyMatt i don't think it's vital to slavishly reproduce every software blend mode. half of them are only there because they were trivial to implement with tables in 8 bit
18:12:10 allefant i don't see why not
18:12:33 allefant yeah. set_dodge_blender, set_dissolve_blender, set_hue_blender.. we won't need those i think
18:12:40 MattyMatt nobody uses them, or if they do they would be happy to switch to sth more GL friendly
18:12:42 allefant the compatibility layer can keep them of course, in software only
18:13:16 trentg OK, so what's al_set_blender going to look like?
18:14:13 trentg I guess we can figure that out after we see what glBlend takes.
18:14:33 allefant yep
18:14:43 allefant and we only need one flag AL_BLEND
18:15:01 allefant al_set_blender can define if that only blends to a single color, to the destination, or both
18:15:54 allefant so AL_BLEND, AL_HORIZONTAL_FLIP and AL_VERTICAL_FLIP are the flags we keep
18:16:16 allefant that is, i just realize
18:16:22 allefant is there much point in AL_BLEND?
18:16:35 allefant could just use al_set_blender(AL_NONE)
18:16:39 allefant to display it
18:16:44 allefant to disable it
18:16:58 allefant it's unlikely you need to send a blender, than blit bitmaps with and without it
18:17:04 allefant *set
18:18:01 trentg I'd like to keep it I think.
18:18:05 Tigge has quit ()
18:18:29 allefant so what happens if you don't specify it?
18:18:31 trentg Well, I'm open on it.
18:18:55 trentg Yeah, that's a good point.
18:18:57 allefant the alpha channel is what got me thinking..
18:19:04 MattyMatt brb. how many sugars everybody?
18:19:18 trentg None for me, thanks :)
18:20:03 trentg OK, I think we can do it like that.
18:20:16 allefant i opened a 2 litre coke bottle, and 3/4 of it are empty by now.. so i think i need nothing :)
18:21:31 allefant void al_blit(int flag, AL_BITMAP *source, AL_BITMAP *dest, int dest_x, int dest_y);
18:21:48 allefant al_draw_bitmap(int x, int y, AL_BITMAP *bitmap, int flags)
18:22:05 allefant ^ i think i would prefer that
18:22:14 allefant but not really important deciding on that right now
18:22:28 allefant once we have the vtables, we can always do an API-naming-overhaul
18:22:57 trentg I'm not sure how to implement sub bitmaps.
18:23:48 trentg I guess it's not that hard.
18:23:56 allefant in OpenGL, you can specify texture coordinates
18:24:19 allefant i think AllegroGL just modifies those in all blit functions, for sub-bitmaps
18:24:32 allefant and for memory bitmaps, it's just an offset
18:25:03 trentg I also think al_acquire_bitmap should take x, y, w, h.
18:25:09 allefant al_blit_region
18:25:19 allefant ^ that would basically do the same as sub-bitmaps
18:25:32 trentg OK.
18:26:06 trentg Because when you acquire it, you don't want to upload the whole thing if only a small bit changed.
18:26:21 allefant true
18:26:34 allefant al_acquire_region() maybe
18:27:12 allefant then al_release_bitmap would then just need to update that specified region
18:28:11 allefant maybe we should drop them though
18:28:20 allefant else we get the same confusion as in 4.2
18:28:36 allefant there should be a way to obtain direct access to pixels
18:28:46 allefant but no general "acquiring" of bitmaps to draw to them
18:28:55 allefant since with render-to-texture, that is nonsense
18:30:19 MattyMatt I've never used acquire
18:30:37 allefant same here
18:30:54 MattyMatt because it's always been for performance tuning on certain platforms
18:31:01 allefant yeah
18:31:10 MattyMatt and none of my apps have ever reached that stage :p
18:31:16 allefant but i've seen some a.cc threads where users were very confused about it
18:31:26 allefant like, acquiring any bitmap before accessing it
18:31:41 allefant therefore making things go much slower instead of faster
18:32:15 MattyMatt yep, so maybe the docs should have it moved to the Platform Specifics chapter
18:32:34 allefant nah, i think platform specifics are bad
18:32:36 trentg I think we should keep acquire
18:32:42 allefant the point of allegro is to work the same across platforms
18:32:57 trentg Because, e.g. for putpixel, if you have a lot, you don't have to re-upload after each one.
18:33:10 allefant hm
18:33:20 allefant wouldn't you directly modify the texture though?
18:33:56 trentg Hm.. you would need to modify the memory copy too anyway, though.
18:33:57 MattyMatt it depends how the flags are set
18:34:06 allefant yes, depends on the flags
18:34:52 allefant usually, i wouldn't want to keep memory in sync all the time, i think
18:35:16 Tigge (n=tigge@bacchus.olf.sgsnet.se) has joined #allegro-dev
18:35:16 ChanServ gives voice to Tigge
18:35:53 allefant acquire basically would mean: sync the memory copy to the texture, and from now on, do not update the texture any longer, but only use software rendering on the bitmap
18:36:06 allefant release then would say: ok, update the texture, and do proper rendering again from now on
18:36:28 allefant additionally, you would be allowed to directly modify pixels in the memory copy in the meantime
18:36:43 MattyMatt yeah that sounds right
18:36:59 trentg Yeah. I'm still confused about the flags, but we'll get that sorted after some more experience I guess.
18:37:09 MattyMatt that's essentially what it's supposed to be doing anyway with ddraw surfaces
18:37:32 allefant yeah, D3D and OpenGL are our main scenarios i think
18:37:44 allefant a direct frame-buffer port will be easy then
18:37:56 allefant (like, X11 or GDI)
18:38:39 MattyMatt yeah
18:38:44 allefant hm, al_set_bitmap_filter
18:38:50 allefant that should go i think
18:39:14 allefant or at least, needs a better proposal than one single function
18:39:26 allefant e.g. if we have filtering for scaling/rotation, then why not for other stuff
18:40:27 MattyMatt yeah 2xSAI could be implemented as a filter for blit
18:41:13 MattyMatt although that would be horribly slow in software unless it works in scanlines
18:41:55 MattyMatt and would prolly need pixel shaders to do in D3D/GL
18:41:55 trentg We could have al_set_bitmap_filter(ROTATE, BILINEAR) or something.
18:42:29 MattyMatt filters could have their own little vtables
18:44:44 MattyMatt ->init ->exit ->hline ->hline3 ->hline5
18:45:23 trentg Will bmp_write_region affect the memory or video copy?
18:45:31 MattyMatt hline3 and 5 would take 3 or 5 source lines for convolution filters
18:51:22 allefant i think we should close the meeting :)
18:51:48 allefant we can still discuss this anytime, anyway
18:51:57 trentg Why? It's only been 5hrs :)
18:52:00 allefant hehe
18:52:16 trentg OK then.
18:52:23 allefant well, it doesn't look like we'll quickly come up with some final API, which would be interesting for someone reading the logs
18:53:26 allefant i'll put up logs and update the wiki, if nobody else does..