Sign in to follow this  

Unity Our future with Longhorn?

This topic is 4671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I read this morning that MS is finally going to release the first beta version of Windows Longhorn this summer - which got me thinking about how the next Windows will effect the game development community. I know it's probably way, way, WAY too early to be speculating about Longhorn - but I'm still curious to any opinions you all may have?

Share this post


Link to post
Share on other sites
From everything I've heard, longhorn is going to be a complete failure. They started out with tons of features good for the masses and annoying for me, but they canceled all those features so now they're left with a rewritten XP for those that need 3" window borders and size 72 font because they can't see the 1" versions with size 24.

Share this post


Link to post
Share on other sites
We are doomed! We'll burn in h... Oh. Sorry.

Er.

Longhorn can't break everything. There are too many games which use current technologies, and I believe we'll be able to continue to use them. I personnally wait the fully shaderified pipeline that is supposed to come with longhorn - because there are so many great things that can be done with a unified shader pipeline...

So I guess 1) we'll be able to continue to play with our current technologies and 2) we'll have very funny things to try :)

Anyway, I'm waiting it :)

Regards,

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
From everything I've heard, longhorn is going to be a complete failure. They started out with tons of features good for the masses and annoying for me, but they canceled all those features so now they're left with a rewritten XP for those that need 3" window borders and size 72 font because they can't see the 1" versions with size 24.


Hi Extrarius

I bet they will call it "MS Windows Managed XP.net 2009".

(Although I agree with you, let's speak about the technologies and the programming point of view - or let's move this thread to the lounge ;))

Kind Regards,

Share this post


Link to post
Share on other sites
Actually, I'm quite excited for Longhorn. I'm not sure what features will be exposed to the user, but on the developer side I'll be very happy to see GDI's replacement by Avalon, plus the introduction of other managed APIs. Even Avalon by itself will be neat. My laptop runs at 1680x1050, and at default font sizes my eyes seriously ache, so an improved UI that scales with resolution will be really nice for me and my parents.

There are other improvements beneath the surface as well, including the addition of a new printing subsystem. True, the benefits might not be immediately visible to the end-user, but for developers it'll be great.

Share this post


Link to post
Share on other sites
I'm interested in Avalon, but apparently that'll be ported over to XP as well.

It'll probably be performance that makes my decision. Before my computer esploded, it was a XP2000+ w/ 512mb of ram, and everything was lightning quick. Everything opened quickly, compile times weren't bad, and restarts didn't even give me enough time to pour myself a coke. I'm currently saving up for a new computer, and I won't settle for anything less.

Share this post


Link to post
Share on other sites
Whenever I read anything about longhorn, it reminds me of the second system effect. For those who haven't read "The Mythical Man-Month" or who haven't heard of the second system effect in a software engineering course, the second system effect states that the second system a developer makes is typically disastrous. When the developer makes the first system, he knows that he is inexperienced and therefore keeps the system very slim, not trying to do too much. Every time he encounters an interesting idea for a feature, he stores that idea away for "next time." When next time, aka, the second system, finally comes around, every single interesting feature gets stuck into the system and it becomes bloated and cumbersome, eventually destined for failure.

If you don't count dos (and you shouldn't), then Longhorn is essentially Microsoft's second operating system. 95 was a revision of 3.1, 98 was a revision of 95, 2000 was a revision of 98, merged with the NT line, and XP was a revision of 2000. Longhorn is their first attempt to start over and create something new from the bottom up. Whenever I read the press releases of all the fancy ideas Microsoft has for Longhorn, all I can think of is how bloated and cumbersome it will be if everything that gets proposed actually ends up in there. Sure, some of the features are nice, but it'll still be a bloated POS in the end.

Share this post


Link to post
Share on other sites
Quote:
Original post by cwhite
If you don't count dos (and you shouldn't), then Longhorn is essentially Microsoft's second operating system. 95 was a revision of 3.1, 98 was a revision of 95, 2000 was a revision of 98, merged with the NT line, and XP was a revision of 2000. Longhorn is their first attempt to start over and create something new from the bottom up. Whenever I read the press releases of all the fancy ideas Microsoft has for Longhorn, all I can think of is how bloated and cumbersome it will be if everything that gets proposed actually ends up in there. Sure, some of the features are nice, but it'll still be a bloated POS in the end.


Well that's not really true, I think most people would agree that 95 was pretty close to a complete rewrite of the basic OS kernel, NT is unquestionalby its own OS as is DOS, if you include the first version of windows then your up to 5 including Longhorn.

We were using Longhorn in 2003 as part of a developer early release, and it is amazing even back then it was really stable. I think people are being alittle too hard on them with the delays:) They are writing alot of new code. Don't forget apple started on OS X back in 95. That's 5 years from start to finish, which sounds like the 2001-2006 time that it took microsoft to go from XP to Longhorn.

Cheers
Chris

Share this post


Link to post
Share on other sites
I'm looking forward to it with 'skeptical optimism':P

As I'm sure I will get it for free (maybe not immediately after release, but eventually), I will certainly give it a try. If I don't see the performance I like, then I will go back to XP, as I'm sure many others will/would also.

Share this post


Link to post
Share on other sites
Quote:
Original post by cwhite
If you don't count dos (and you shouldn't), then Longhorn is essentially Microsoft's second operating system. 95 was a revision of 3.1, 98 was a revision of 95, 2000 was a revision of 98, merged with the NT line, and XP was a revision of 2000.


So, even with your count, it is the third :) Anyway, 2000 should be accurately defined by "a revision of NT, merged with the 98 line". The main thing in NT is that it boots in 32 bit mode, and the 16 bit mode is emulated.

Anyway, we are pretty far from the tech discussion here :)

Regards,

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The impact of the OS using the 3D hardware to draw the desktop and applications will be huge.

All running apps sharing the GPU. All of them feeding it piles of small batches. So much has to change in the software (Dx level and drivers) as well as the hardware to make this acceptably fast.

Plus, the driver model puts most of the display driver in user mode (vs kernel mode), this alone is worth switching to longhorn (at least for dev work).

Share this post


Link to post
Share on other sites
The above AP is me.

Also, Windows 3.0, 3.1, 95, and 98 are all graphic shells sitting on top of 16bit MS-DOS. They contain a large amount of 16bit code (even in the Windows API stuff). There's a ton of thunking down to 16bit code across the board even in Win32 functions. These are largely the same OS, 95/98 have the Win32 API grafted on so that they can run most of the same apps that NT runs.

Windows NT, 2000, and XP are actual 32bit OSes build on the NT Kernel. They emulate the 16bit MS-DOS stuff for running old apps. There is little or no thunking to 16bit code going in in a Win32 app on these OSes. These are largely the same OS.

Longhorn will be the 3rd. Of course, it will have a ton of code that already existed in the previous OSes. It has to, in order to run existing apps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster, which is really reltham
The impact of the OS using the 3D hardware to draw the desktop and applications will be huge.

All running apps sharing the GPU. All of them feeding it piles of small batches. So much has to change in the software (Dx level and drivers) as well as the hardware to make this acceptably fast.


I may be wrong, but I believe it was already the case. Since a driver contains entry points for both DX/GL and GDI stuff, most of the GDI is already hardware accelerated in the same way than the DX/GL stuff (or am I completely missing something here?). Again, I'm not sure at all, but it sounds rather logical to me.

Quote:
Original post by Anonymous Poster, which is really reltham again (yes)
Plus, the driver model puts most of the display driver in user mode (vs kernel mode), this alone is worth switching to longhorn (at least for dev work).


Wow. I'd like to have some explaination here. What is this user mode driver thingy?

Regards,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Wow. I'd like to have some explaination here. What is this user mode driver thingy?

Regards,


Since the driver is in user mode, if it crashes it will only bring down the program its currently runing for, not the whole OS. No more rebooting due to driver lockups..... well in theory anyway:)

Cheers
Chris

Share this post


Link to post
Share on other sites
it will also make calls for D3D less expensive, as atm the driver has to switch from user to kernel and then back again, which causes a fair amount of overhead thus why batching is very important in D3D apps (by contrast, OpenGL lives in User space which makes its vertex array drawing functions much lighter, between 2.3 => 1.7x faster, the difference becoming less as the batch sizes increase)

Share this post


Link to post
Share on other sites
Quote:
Original post by chollida1
Quote:
Original post by Emmanuel Deloget
Wow. I'd like to have some explaination here. What is this user mode driver thingy?

Regards,


Since the driver is in user mode, if it crashes it will only bring down the program its currently runing for, not the whole OS. No more rebooting due to driver lockups..... well in theory anyway:)

Cheers
Chris


:/ I was expecting something more intelligent. This would have been possible if Windows was using a microkernel - shut down the faulty kernel module, restart it, and voilà. It seems they are going to try to implement a microkernel architecture on the top of a non microkernel architecture just to say "hey! it didn't blow the whole thing!". Moreover, it won't prevent against the BSOD bugs - since they typically arrive during low IRQL, and such low IRQL is typically needed to handle interrupt requests... Well... Wait and see :)

Anyway, thanks for your clarification :)

Regards,

Share this post


Link to post
Share on other sites
This is a little off topic from game programming, but since it is in the "General Programming" Forum I thought I would mention that nobody has mentioned WinFX yet ( http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031107WINFXBA/manifest.xml ).
I have only took a quick glance at it, but is sounds like to Longhorn GUI model is designed to be independent of the code behind it. Its also XML based. While this doesn't mean much for consumers, developers may need to get used to the change in how graphical components are specified in Windows Longhorn. This is one of the few impressive features I have heard about Longhorn that have been anounced so far.

Share this post


Link to post
Share on other sites
Quote:
Original post by wyrzy
This is a little off topic from game programming, but since it is in the "General Programming" Forum I thought I would mention that nobody has mentioned WinFX yet ( http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031107WINFXBA/manifest.xml ).
I have only took a quick glance at it, but is sounds like to Longhorn GUI model is designed to be independent of the code behind it. Its also XML based. While this doesn't mean much for consumers, developers may need to get used to the change in how graphical components are specified in Windows Longhorn. This is one of the few impressive features I have heard about Longhorn that have been anounced so far.


I'm still a little dubious about this issue. I remember that Win98 was using a HTML-based GUI, from what MS said at this moment... :) Anyway, I'll check this ASAP.

Regards,

Share this post


Link to post
Share on other sites
If MS deliver on what they're promising Longhorn should be great for games / 3D. Google for Windows Graphics Foundation to find some info on plans for the underlying graphics architecture / next version of D3D. GDI/GDI+ currently get no benefit from 3D hardware acceleration although they do use some 2D hardware acceleration. The potential benefits of having the UI take advantage of the full power of the 3D hardware are huge but the potential problems from a performance point of view (multi-tasking on the GPU) could be a downer. Moving the bulk of D3D / driver work from kernel mode to user mode should be good for both performance and stability. The OS requiring minimum shader model 2.0 compliant graphics hardware is good because it should mean we as developers don't have to deal with so many crappy, underpowerd integrated graphics cards. There's also some exciting features looming for D3D which should be exposed in WGF on Longhorn and they will enable quite a few interesting new graphical techniques and performance optimizations.

The continual slippage and dropped features are a bit worrying but if MS deliver on the WGF promises it will be pretty cool.

Share this post


Link to post
Share on other sites
The hardware acceleration used by GDI currently is 2D Blitting, and a hardware cursor (sprite) if available. The 3D pipelines are sitting idle during 2D operations.

If GDI used the 3D pipelines for rendering right now it would crawl due to batch overhead (state change stalls, user/kernel mode switches, and so on). Plus, it would use a more video memory to hold the UI elements as textures, have a backbuffer, and have VBs for rendering those elements. Then there is the whole power of two texture size issue.

As for the comment above about Longhorn requiring a SM 2.0 level GPU, that's inaccurate. Check this link: Graphics Reqs
They have a "Classic Experience" mode that they describe as Windows 2000 like using software rendering. The "Aero Experience" and "Aero Glass Experience" require Pixel Shader 2.0 (Vertex Shader 2.0 is only recommended).

[Edited by - reltham on February 9, 2005 5:01:34 PM]

Share this post


Link to post
Share on other sites
Quote:
'm still a little dubious about this issue. I remember that Win98 was using a HTML-based GUI, from what MS said at this moment... :) Anyway, I'll check this ASAP.


XAML is the name of the XML thing used in Avalon and it's rather nice [smile]. For anyone wanting to take a look at Avalon, the novemember CTP is publically available here.

I am personally rather looking forward to Longhorn. Things like Avalon and WinFS look interesting. From my limited experience of Avalon it looks like it makes developing GUIs a whole lot easier plus as it finally does away with GDI you can do all kinds of fancy effects.

Share this post


Link to post
Share on other sites
XAML is pretty cool but I think its biggest win is that you no longer need a programmer to do teh UI. Once its setup a program manager can go in and tweak the UI with out having to code.

Furthermore you can create all sorts of sku's of your app by removing functionality to create a "lite" version or changing the UI to gear it towards a certain group of people.

It will let program managers "manage" the UI of their app and free developers from having to do teadious UI tasks.


Cheers
Chris

Share this post


Link to post
Share on other sites
Quote:
Original post by Monder
XAML is the name of the XML thing used in Avalon and it's rather nice [smile]. For anyone wanting to take a look at Avalon, the novemember CTP is publically available here.

Thanks.

Quote:
Original post by Monder
I am personally rather looking forward to Longhorn. Things like Avalon and WinFS look interesting. From my limited experience of Avalon it looks like it makes developing GUIs a whole lot easier plus as it finally does away with GDI you can do all kinds of fancy effects.


Well, WinFS is delayed AFAIK.

Regards,

Share this post


Link to post
Share on other sites

This topic is 4671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628707
    • Total Posts
      2984310
  • Similar Content

    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
    • By Dafu
      Hello all,
      I've been hard at work on a new retro pixel-perfect framework called FES Retro Game Framework. It is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      My own game I started working on using FES, a roguelike, very early: https://simmer.io/@Dafu/merl
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
       
       
    • By Apollo Cabrera
      Yasss!!! My first Unity3d game is on the App Store and Google Play.
      Download please! About 30 minutes to get through 5 missions.
      Let me know what you guys think.
      Thanks a bunch
       
    • By Mert Oguz
      well, i have started developing games last year, alone , I made a singleplayer 3d openworld rpg on unity you can look at it on googleplaystore ( kooru stone rpg ) whatever, this year, i wanted to make mmo, which gone really fine until I first try real hosting, I was working on "wamp" until then. The reason i am desperate now is that the way my game works.
      On my pc, using wamp mysql , with localhost as host for my game, i was testing my mmorpg with using andorid emulators, ofcourse no lag no issues no restrictions, beautiful dream... But then, I wanted to get real host from web, so, I rent a basic, cheaphest ever web host ( 10$ year ), and transferred my php files along with sql database. 
      So, I launched the game, still no issues, tried to handle 2-3 players by using my pc, phone, friend's phone...  
      After a while, ( after really short time (3-4mins)) host started not to respond, beacause those web hosting were not fit to handle mmos, i predicted that.
      now what i am explaining is that my game works like this and asking what way should i use to handle it :
      - Creates web request ( like : webhost.com/game/getplayerdata.php?ID=2 )
      -Reads request ( request result be like = "ID2-GoodGuyXx-23-123-4-123-43 )
      -Builds player using result string
      -does similar requests REEAALY FREQUENTLY  ( total requests of 8 - 12 times per seconds )
      With my current ultimate cheap web hosting, i can handle 2 players with low lag ( lol ) but, i want to handle around 20-100 players,
      just need a clear path, i have been struggling with google cloud sql and other vps server dedicated server options, i dont wanna pay much and get ripped off.
  • Popular Now