Thread: [GD-General] Graphic Library and market share
Brought to you by:
vexxed72
From: Sebastian U. <li...@in...> - 2004-01-06 17:21:25
|
### Note: Sorry if this appears twice, i first sent it with another email address (not subscripted to the list) but it's still awaiting moderator approval ### Hi, We're making some small puzzle game for Win32 to be (hopefully) distributed online. We're currently using SDL (as we had planned to make it easily portable), but some problems with it are slowing down our development (timer granularity and slow alpha blitting mostly). So we're thinking in using DirectX for now, and later care about other platforms. I wanted to get some idea about the installed base of DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7 must come with W2K. We don't care a lot about W98 right now (¿Should we?). Our programmers say DX8 will be easier to use tan DX7, but I'm worried it will restrict our market share, as we're not targeting hardcore gamers (with the latest in machine and OS). ¿What's your experience with this? Any comment will be appreciated! PD: I believe OpenGL would probably be well suited also, but the main programmer in this proyect feels more comfortable with DX. Thanks -- /// Sebastián Uribe Inmune Games su...@in... www.inmune.com.ar |
From: brian s. <pud...@po...> - 2004-01-06 22:10:38
|
Switching to DirectX won't necessarily fix your alpha-blending problems, as the crappy machines are also the least likely to support hardware-accelerated 2D blits (I'm just assuming 2D here as you're using SDL). Of course you can switch to a 3D API and get blending done by the hardware, but then you'll be requiring hardware acceleration for a 2D game, which is probably not what you want to do :) I would guess that you're setting up your back buffer in video memory and rendering your sprites there. What kills you there is the need to read rendered pixel values back off the video card so that the CPU can do the alpha blend between source and destination. Transferring data back from the video card is slooooooow. I had the same problem with an SDL app a couple of years ago. Here's how I set things up to fix it: * render the entire frame to a buffer in system memory (with alpha-blending enabled) * do one large screen-sized copy blit from system memory to the back buffer on the video card * flip the back buffer to the front Switching to rendering in system memory provided a significant performance boost for me. I'd try that before you rewrite your app. --brian Sebastian Uribe wrote: > ### > Note: Sorry if this appears twice, i first sent it with another email > address (not subscripted to the list) but it's still awaiting > moderator approval > ### > > Hi, > > We're making some small puzzle game for Win32 to be (hopefully) > distributed online. We're currently using SDL (as we had planned to > make it easily portable), but some problems with it are slowing down > our development (timer granularity and slow alpha blitting mostly). > So we're thinking in using DirectX for now, and later care about > other platforms. I wanted to get some idea about the installed base of > DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or > DX7 must come with W2K. We don't care a lot about W98 right now > (¿Should we?). Our programmers say DX8 will be easier to use tan DX7, > but I'm worried it will restrict our market share, as we're not > targeting hardcore gamers (with the latest in machine and OS). > > ¿What's your experience with this? Any comment will be appreciated! > > PD: I believe OpenGL would probably be well suited also, but the main > programmer in this proyect feels more comfortable with DX. > > Thanks > |
From: Sebastian U. <li...@in...> - 2004-01-08 17:16:21
|
We'll give that a try first then, before trying the switch to dx. Thanks for the advice! I also remember we had some problems with the handling of HWSURFACEs and back buffer (some strange things with the color channels changing when we switched between fullscreen and window mode), but due to our inexperience with SDL we aren't sure if it's our fault or SDL (we *do* know that there were some bugs with ARGB -> ARGB surface blitting, didn't find any reference to this solved on the web - will keep looking for answers :) ). So all this problems are pushing us to try other rendering library... And as I said before, we don't want to restrict our target audience (by using "slow" SDL or "fast-hardware-demanding" DX). brian sharon wrote: > Switching to DirectX won't necessarily fix your alpha-blending > problems, as the crappy machines are also the least likely to support > hardware-accelerated 2D blits (I'm just assuming 2D here as you're > using SDL). Of course you can switch to a 3D API and get blending > done by the hardware, but then you'll be requiring hardware > acceleration for a 2D game, which is probably not what you want to do :) > > I would guess that you're setting up your back buffer in video memory > and rendering your sprites there. What kills you there is the need to > read rendered pixel values back off the video card so that the CPU can > do the alpha blend between source and destination. Transferring data > back from the video card is slooooooow. > I had the same problem with an SDL app a couple of years ago. Here's > how I set things up to fix it: > > * render the entire frame to a buffer in system memory (with > alpha-blending enabled) > * do one large screen-sized copy blit from system memory to the back > buffer on the video card > * flip the back buffer to the front > > Switching to rendering in system memory provided a significant > performance boost for me. I'd try that before you rewrite your app. > > --brian -- /// Sebastián Uribe Inmune Games su...@in... www.inmune.com.ar |
From: Marin K. <m.k...@in...> - 2004-01-17 15:28:30
|
> We're making some small puzzle game for Win32 to be (hopefully) > distributed online. We're currently using SDL (as we had planned to make > it easily portable), but some problems with it are slowing down our > development (timer granularity and slow alpha blitting mostly). > So we're thinking in using DirectX for now, and later care about > other platforms. I wanted to get some idea about the installed base of > DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7 > must come with W2K. We don't care a lot about W98 right now (¿Should > we?). Our programmers say DX8 will be easier to use tan DX7, but I'm > worried it will restrict our market share, as we're not targeting > hardcore gamers (with the latest in machine and OS). If you're going to use DDraw then you're using DX7 anyway, and it comes with W2k, AFAIK. However, be careful with this because there is a whole range of old nVidia drivers with broken DDraw support that exibit rather severe visual glitches when your backbuffer is in system memory (which it needs to be for alpha-blending). This has been an endless source of pain for us. If I was rewriting our stuff today, I'd ditch any hw-accel altogether and go with GDI, or *possibly* require 3d hw and go with D3D8. Regards, Marin Kovacic Lemonade Productions http://www.lemonade-p.com |
From: brian s. <pud...@po...> - 2004-01-17 22:07:17
|
You should leave your back buffer in video memory and do your rendering into a screen-sized surface in system memory. Then just copy the sysmem surface to the back buffer every frame. That gets you back on the well-tested driver path, and it isn't any more expensive - you have to copy a screen's worth of data from sysmem to vidmem in either case, and the flip of the vidmem back buffer to the front is free. --brian On Saturday, January 17, 2004, at 07:27 AM, Marin Kovacic wrote: > However, be careful with this because > there is a whole range of old nVidia drivers with broken DDraw > support that exibit rather severe visual glitches when your backbuffer > is in system memory (which it needs to be for alpha-blending). This > has been an endless source of pain for us. |
From: Marin K. <m.k...@in...> - 2004-01-18 16:26:01
|
> You should leave your back buffer in video memory and do your rendering > into a screen-sized surface in system memory. Then just copy the > sysmem surface to the back buffer every frame. That gets you back on That's pretty much what we were going to do next, except we'll keep the "real" backbuffer in "raw" system memory (not dd surface) to avoid any additional driver issues. Most of our blits are either alpha-blended or paletted, so having to blit everything ourselves is not an issue as we do it anyway. Thanks, Marin Kovacic Lemonade Productions http://www.lemonade-p.com |
From: Marin K. <m.k...@in...> - 2004-01-17 15:34:43
|
> DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7 > must come with W2K. We don't care a lot about W98 right now (¿Should > we?). Our programmers say DX8 will be easier to use tan DX7, but I'm > worried it will restrict our market share, as we're not targeting > hardcore gamers (with the latest in machine and OS). Oh, and for the market share - here are our web stats for January. It's not a lot of traffic, but should be somewhat statisticaly relevant: Operating System Hits Visitors % of Total Visitors 1 Windows XP 30,219 6,296 59.71% 2 Windows 98 7,922 1,848 17.52% 3 Windows 2000 6,953 1,042 9.88% 4 Windows ME 2,582 675 6.40% 5 Others 1,625 414 3.93% 6 Windows NT 660 120 1.14% 7 Windows 95 157 56 0.53% 8 Mac OS 647 47 0.45% 9 Linux 204 28 0.27% 10 Windows Win32s 24 15 0.14% 11 FreeBSD 2 2 0.02% 12 MSN TV (WebTV) 1 1 0.01% 13 Sun OS 1 1 0.01% -- Marin Kovacic Lemonade Productions http://www.lemonade-p.com |
From: Marin K. <m.k...@in...> - 2004-01-17 15:45:49
|
> Oh, and for the market share - here are our web stats for January. > It's not a lot of traffic, but should be somewhat statisticaly relevant: > Operating System Hits Visitors % of Total Visitors > 1 Windows XP 30,219 6,296 59.71% > 2 Windows 98 7,922 1,848 17.52% > 3 Windows 2000 6,953 1,042 9.88% > 4 Windows ME 2,582 675 6.40% Actualy, now that I look at these figures I believe they are skewed towards WinXP a bit. Usually they look more like this (stats for October): Operating System Hits Visitors % of Total Visitors 1 Windows XP 12,639 2,154 47.63% 2 Windows 98 6,592 1,057 23.37% 3 Windows 2000 2,549 427 9.44% 4 Others 1,010 360 7.96% 5 Windows ME 1,882 352 7.78% 6 Windows NT 563 69 1.53% -- Marin Kovacic Lemonade Productions http://www.lemonade-p.com |
From: Daniel V. <vo...@ep...> - 2004-01-20 18:16:05
|
Query date 01/08/2004 UT2003 Client Server WinXP 75.59 % 27.98 % Win98/ME 11.08 % 1.32 % Win2K 9.94 % 35.96 % Linux/X86 2.07 % 34.03 % Mac 1.26 % 0.35 % WinNT 0.04 % 0.01 % Query date 12/28/2002 UT2003 Client Server WinXP 67.78 % 15.62 % Win98/ME 19.63 % 2.74 % Win2K 11.87 % 34.96 % Linux/X86 0.69 % 40.66 % WinNT 0.00 % 6.03 % The "server" number is based on current online servers at the time of the query and the "client" number is based on the last OS used by a CD key that has been online at least once (aka, connected to our masterserver). The Mac numbers are not representative for market share as the release lagged behind by quite a bit and there were also other factors though UT2004 should yield representative numbers as we're shooting for a simultaneous release. -- Daniel, Epic Games Inc. |
From: Toni <to...@4d...> - 2004-01-20 20:52:45
|
Well, even when data is nice to see (i like that linux growth in servers and clients and well, i see the XP shifting too) I think data is not representative. I mean if you don't have the number of players/connections whatever you can't compare both data statistics, am i right?. I mean, i don't know how successful UT2003 is but it could be easily biassed, for example because there are less people that plays UT2003 (i don't know that, i've never played ut2003) than in 2002 (that would explain, for example the linux growth, as there are less fps in linux than in windws). Just my 2 cents Toni Lead Designer/Programmer insideo.com |
From: Daniel V. <vo...@ep...> - 2004-01-20 21:00:19
|
Take the data for what it's worth though there are two wrong statements in your post. First, Linux server percentage decreased from 40 to 33 percent and second, the client percentages are explicitely not current online numbers but numbers over lifetime like explained in my original post. > I mean if you don't have the number of players/connections Sorry, won't post absolute numbers. -- Daniel, Epic Games Inc. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Toni > Sent: Tuesday, January 20, 2004 3:56 PM > To: gam...@li... > Subject: Re: [GD-General] OS split for UT2003 > > Well, even when data is nice to see (i like that linux growth > in servers and clients and well, i see the XP shifting too) I > think data is not representative. > I mean if you don't have the number of players/connections > whatever you can't compare both data statistics, am i right?. > I mean, i don't know how successful UT2003 is but it could be > easily biassed, for example because there are less people > that plays UT2003 (i don't know that, i've never played > ut2003) than in 2002 (that would explain, for example the > linux growth, as there are less fps in linux than in windws). > > Just my 2 cents > > Toni > Lead Designer/Programmer > insideo.com |
From: toni <to...@4d...> - 2004-01-21 08:44:35
|
Daniel Vogel wrote: >Take the data for what it's worth though there are two wrong statements in >your post. > Yeah, sorry i was a bit asleep when i read/replied your mail :) >>I mean if you don't have the number of players/connections >> >> > >Sorry, won't post absolute numbers. > > I didn't mean you have to post absolute numbers, i only meant these stats would be more useful with that numbers, but they are still useful without them. Toni Lead Designer/Programmer insideo.com |
From: Alen L. <ale...@cr...> - 2004-02-10 07:26:58
|
Hi, I'm evaluating video codecs for FMVs, and have currently looked into Bink and DivX. Are there any others worth checking? Thanks, Alen |
From: Ivan-Assen I. <as...@ha...> - 2004-02-10 09:47:30
|
> I'm evaluating video codecs for FMVs, and have currently looked into Bink > and DivX. Are there any others worth checking? The Microsoft MPEG-4 v2 codec, the spiritual ancestor of DivX, is certainly a worthy contender in terms of quality/compression ratio, and a decoder is installed along with DirectX 8 and later, so you don't have to worry about compatibility. |
From: ~BG~ <arc...@ma...> - 2004-02-10 16:06:54
|
3ivx and XviD... Both are MPEG4 advanced simple profile alternatives to DivX... 3ivx is a commercial codec like DivX, while XviD is an open source GPL codec. There's also Ogg Theora which is built off of On2's VP3 codec, but it's at a pretty rough alpha stage right now (but should have pretty loose restrictions on use like Ogg Vorbis) On Feb 10, 2004, at 12:30 AM, Alen Ladavac wrote: > I'm evaluating video codecs for FMVs, and have currently looked into > Bink > and DivX. Are there any others worth checking? > > Thanks, > Alen |
From: Dan T. <da...@ar...> - 2004-02-10 19:49:12
|
XVid I had problems installing under limited user access, so I wouldn't go with that. Couldn't figure out why a video codec needed admin access, but it wouldn't run without it. I was most bitter. Bink and Smacker seem to do pretty nicely from what I've seen, and they've been around so long that the tech should be incredibly mature. I decompressed a smacker(bink?) video off of the Mechwarrior 2 cd i had lying around.. and thats an old (but awesome!) game. Ogg Vorbis is also nifty, but I also had problems getting it work under LUA. Finally got it to work, but it was a trial, let me tell you. -Dan ----- Original Message ----- From: "~BG~" <arc...@ma...> To: <gam...@li...> Sent: Tuesday, February 10, 2004 8:06 AM Subject: [email] Re: [GD-General] Video codecs > 3ivx and XviD... Both are MPEG4 advanced simple profile alternatives > to DivX... 3ivx is a commercial codec like DivX, while XviD is an open > source GPL codec. > > There's also Ogg Theora which is built off of On2's VP3 codec, but it's > at a pretty rough alpha stage right now (but should have pretty loose > restrictions on use like Ogg Vorbis) > > On Feb 10, 2004, at 12:30 AM, Alen Ladavac wrote: > > > I'm evaluating video codecs for FMVs, and have currently looked into > > Bink > > and DivX. Are there any others worth checking? > > > > Thanks, > > Alen > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |