Im doing a bit of experimentation with MonoGame and F# its a pity we cant try to make an impact with that pairing.
Why not?
Performance isn't amazing, I can't see it been using for any 'proper' games just mobile gaming. I don't really play games on my mobile so Im not the right person to build those games I guess :)
Wow, the submit button said failed to add comment so I kept clicking ...
Right - looks like a bug slipped through in yesterday's update. Please REFRESH the page after adding a comment (even if it says it failed to add it) - it should be there. Sorry about the confusion, will fix tomorrow.
The bug should be fixed now.
Edit - Yep, didn't have any problem with this comment. The bug was an inconsistency within our database cache when commenting on topics with certain tags.
Edit - Yep, didn't have any problem with this comment. The bug was an inconsistency within our database cache when commenting on topics with certain tags.
I agree on the point around shaders. But general functional programming would have to be optimised to a certain extent, would this optimisation invalidating using functional in the first place. An area for experimentation may be around forfeiting speed for easy parallelism and time to market. A killer app would have to be made to make any form of wave in this arena...
I agree on the point around shaders. But general functional programming would have to be optimised to a certain extent, would this optimisation invalidating using functional in the first place.
An area for experimentation may be around forfeiting speed for easy parallelism and time to market. A killer app would have to be made to make any form of wave in this arena...
An area for experimentation may be around forfeiting speed for easy parallelism and time to market. A killer app would have to be made to make any form of wave in this arena...
I agree on the point around shaders. But general functional programming would have to be optimised to a certain extent, would this optimisation invalidating using functional in the first place.
An area for experimentation may be around forfeiting speed for easy parallelism and time to market. A killer app would have to be made to make any form of wave in this arena...
An area for experimentation may be around forfeiting speed for easy parallelism and time to market. A killer app would have to be made to make any form of wave in this arena...
I don't think the general population of game developers understands this. To get things to change, we need to show game programming truly benefits from functional programming.
Unfortunately, that's hard to show using a demo tech, precisely because of the problem we want to solve.
An area where FP would shine is shaders. Immutability is already imposed by the GPU architecture, but the existing shader programming languages aren't very functional. This leads for instance to shaders being hard to compose. I've seen solutions to this problem using graphs and pipelines, which I see as some sort of graphical (limited) functional programming. I write "limited" because higher-order functions are not supported.
A small and simple functional language with a good syntax for vector math could be successful.
Unfortunately, that's hard to show using a demo tech, precisely because of the problem we want to solve.
An area where FP would shine is shaders. Immutability is already imposed by the GPU architecture, but the existing shader programming languages aren't very functional. This leads for instance to shaders being hard to compose. I've seen solutions to this problem using graphs and pipelines, which I see as some sort of graphical (limited) functional programming. I write "limited" because higher-order functions are not supported.
A small and simple functional language with a good syntax for vector math could be successful.
Ya, it becomes quite a mess with the current composition techniques, esp. in terms on debugging.
This brings up something that I can't even fathom currently. Could GPU's someday have garbage collectors? Could they, with the right programming, have them now? It all rather blows my mind due to my lack of understanding of GPUs at the low level (I've only used HLSLs).
This brings up something that I can't even fathom currently. Could GPU's someday have garbage collectors? Could they, with the right programming, have them now? It all rather blows my mind due to my lack of understanding of GPUs at the low level (I've only used HLSLs).
This brings up something that I can't even fathom currently. Could GPU's someday have garbage collectors? Could they, with the right programming, have them now? It all rather blows my mind due to my lack of understanding of GPUs at the low level (I've only used HLSLs).There is no heap, so no need for GC. This might change if GPUs evolve toward CPUs, but currently I don't see a need for GC on GPUs.
Still, without a heap any kind of real FP breaks down. Maybe you could do it with combinators like Scala does with Spark though.
Still, without a heap any kind of real FP breaks down. Maybe you could do it with combinators like Scala does with Spark though.
Still, without a heap any kind of real FP breaks down. Maybe you could do it with combinators like Scala does with Spark though.
Still, without a heap any kind of real FP breaks down. Maybe you could do it with combinators like Scala does with Spark though.
And one thing that game developers would immediately understand is that game scripting really does require a real-time GC. If you want to bridge that understanding gap, bring up that point :)
Topic tags
- f# × 3660
- compiler × 263
- functional × 199
- c# × 119
- websharper × 114
- classes × 96
- web × 94
- book × 84
- .net × 82
- async × 72
- parallel × 43
- server × 43
- parsing × 41
- testing × 41
- asynchronous × 30
- monad × 28
- ocaml × 26
- tutorial × 26
- haskell × 25
- workflows × 22
- html × 21
- linq × 21
- introduction × 19
- silverlight × 19
- wpf × 19
- fpish × 18
- collections × 14
- pipeline × 14
- templates × 12
- monads × 11
- opinion × 10
- reactive × 10
- plugin × 9
- scheme × 9
- sitelets × 9
- solid × 9
- basics × 8
- concurrent × 8
- deployment × 8
- how-to × 8
- python × 8
- complexity × 7
- javascript × 6
- jquery × 6
- lisp × 6
- real-world × 6
- workshop × 6
- xaml × 6
- conference × 5
- dsl × 5
- java × 5
- metaprogramming × 5
- ml × 5
- scala × 5
- visual studio × 5
- formlets × 4
- fsi × 4
- lift × 4
- sql × 4
- teaching × 4
- alt.net × 3
- aml × 3
- enhancement × 3
- list × 3
- reflection × 3
- blog × 2
- compilation × 2
- computation expressions × 2
- corporate × 2
- courses × 2
- cufp × 2
- enterprise × 2
- entity framework × 2
- erlang × 2
- events × 2
- f# interactive × 2
- fsc × 2
- google maps × 2
- html5 × 2
- http × 2
- interactive × 2
- interface × 2
- iphone × 2
- iteratee × 2
- jobs × 2
- keynote × 2
- mvc × 2
- numeric × 2
- obfuscation × 2
- oop × 2
- packaging × 2
- pattern matching × 2
- pipelines × 2
- rx × 2
- script × 2
- seq × 2
- sockets × 2
- stm × 2
- tcp × 2
- trie × 2
- type × 2
- type provider × 2
- xna × 2
- zh × 2
- .net interop × 1
- 2012 × 1
- abstract class × 1
- accumulator × 1
- active pattern × 1
- addin × 1
- agents × 1
- agile × 1
- android × 1
- anonymous object × 1
- appcelerator × 1
- architecture × 1
- array × 1
- arrays × 1
- asp.net 4.5 × 1
- asp.net mvc × 1
- asp.net mvc 4 × 1
- asp.net web api × 1
- aspnet × 1
- ast × 1
- b-tree × 1
- bistro × 1
- bug × 1
- camtasia studio × 1
- canvas × 1
- class × 1
- client × 1
- clojure × 1
- closures × 1
- cloud × 1
- cms × 1
- coding diacritics × 1
- color highlighting × 1
- combinator × 1
- confirm × 1
- constructor × 1
- continuation-passing style × 1
- coords × 1
- coursera × 1
- csla × 1
- css × 1
- data × 1
- database × 1
- declarative × 1
- delete × 1
- dhtmlx × 1
- discriminated union × 1
- distance × 1
- docs × 1
- documentation × 1
- dol × 1
- domain × 1
- du × 1
- duf-101 × 1
- eclipse × 1
- edsl × 1
- em algorithm × 1
- emacs × 1
- emotion × 1
- error × 1
- etw × 1
- euclidean × 1
- event × 1
- example × 1
- ext js × 1
- extension methods × 1
- extra × 1
- facet pattern × 1
- fantomas × 1
- fear × 1
- float × 1
- fp × 1
- frank × 1
- fsdoc × 1
- fsharp.core × 1
- fsharp.powerpack × 1
- fsharpx × 1
- function × 1
- functional style × 1
- gc × 1
- generic × 1
- geometry × 1
- getlastwin32error × 1
- google × 1
- group × 1
- hash × 1
- history × 1
- hosting × 1
- httpcontext × 1
- https × 1
- hubfs × 1
- ie 8 × 1
- if-doc × 1
- inheritance × 1
- installer × 1
- interpreter × 1
- io × 1
- ios × 1
- ipad × 1
- kendo × 1
- learning × 1
- licensing × 1
- macro × 1
- macros × 1
- maps × 1
- markup × 1
- marshal × 1
- math × 1
- metro style × 1
- micro orm × 1
- minimum-requirements × 1
- multidimensional × 1
- multithreading × 1
- mysql × 1
- mysqlclient × 1
- nancy × 1
- nested × 1
- nested loops × 1
- node × 1
- object relation mapper × 1
- object-oriented × 1
- offline × 1
- option × 1
- orm × 1
- osx × 1
- owin × 1
- paper × 1
- parameter × 1
- performance × 1
- persistent data structure × 1
- phonegap × 1
- pola × 1
- powerpack × 1
- prefix tree × 1
- principle of least authority × 1
- programming × 1
- projekt_feladat × 1
- protected × 1
- provider × 1
- ptvs × 1
- quant × 1
- quotations × 1
- range × 1
- raphael × 1
- razor × 1
- rc × 1
- real-time × 1
- reference × 1
- restful × 1
- round table × 1
- runtime × 1
- scriptcs × 1
- scripting × 1
- service × 1
- session-state × 1
- sitelet × 1
- stickynotes × 1
- stress × 1
- strong name × 1
- structures × 1
- tdd × 1
- template × 1
- tracing × 1
- tsunamiide × 1
- type inference × 1
- type providers × 1
- upload × 1
- vb × 1
- vb.net × 1
- vector × 1
- visual f# × 1
- visual studio 11 × 1
- visual studio shell × 1
- visualstudio × 1
- web api × 1
- webapi × 1
- windows 8 × 1
- windows-phone × 1
- winrt × 1
- xml × 1
|
Copyright (c) 2011-2012 IntelliFactory. All rights reserved. Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us |
Built with WebSharper |
Microsoft may be positioned to allow game development to move to the modern age of programming techniques by allowing practical use of ad-hoc memory allocation and the functional programming techniques enabled by it (not to mention metalinguistic abstraction / language-oriented development). However, what would be required, at a minimum, is an incremental garbage collector for .NET. The collector would have to be boundable to under 1-2 milliseconds. For those who've done the research, these technologies are in use today (google haskell and it's incremental gc for GHC). Once these foundational issues are addressed, XNA can become a truly transformative platform for game development.
It is well known that one can write games with F# by avoiding it's use of nearly all its functional programming facilities or by keeping the heap small by excruciating techniques. In the same vein, one can also cut grass with one's teeth.
What is needed is an incremental GC for .NET. If we were to get game development out of the 90's for the phone, we'll need an incremental GC for the compact framework as well.
Mono is not ready for the changes required to the technology stack. It's too much of a mess in terms of code and organizationally. Nor does it have the resources to make these changes (you can barely get them to fix long-standing framework bugs). So Microsoft, with all it's on-going modern programming developments (F#, C# LINQ, access to Simon Peyton Jones and other equality progressive software researchers, and adequate resources) can be the first company to truly modernize game development.
If interested, please forward to whoever applicable. If these recommendations are already being pursued internally, please publicly announce them when you can.
- Bryan