This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
16
Off-Topic / C++0x and garbage collection
« on: November 14, 2010, 06:06:41 pm »
What happens to variables you forgot to free?
Previously, you'd expect to get a memory leak in C++, but in C++0x, according to wikipedia:
Of course, considering how permissive C++ is regarding memory, decent garbage collectors are nearly impossible, so we're most left with stuff like Boehm's conservative GC.
Note that implementation defined doesn't mean that all implementations GC. Only if the compiler makers decide so.
On GCC, I'd guess garbage collector would end up as some compiler flag.
Previously, you'd expect to get a memory leak in C++, but in C++0x, according to wikipedia:
Quote
It is implementation defined whether unreachable dynamically allocated objects are automatically reclaimed.
Of course, considering how permissive C++ is regarding memory, decent garbage collectors are nearly impossible, so we're most left with stuff like Boehm's conservative GC.
Note that implementation defined doesn't mean that all implementations GC. Only if the compiler makers decide so.
On GCC, I'd guess garbage collector would end up as some compiler flag.
17
Off-Topic / Wayland (aka DIE X11 DIE)
« on: November 05, 2010, 09:25:28 am »
The FOSS guys finally discovered that X11 sucks so bad, so they're finally starting to develop a replacement.
So eventually X11 will only be a backwards compatibility layer, like it is on Mac right now.
Awesome.
So eventually X11 will only be a backwards compatibility layer, like it is on Mac right now.
Awesome.
18
Off-Topic / Slow compile times for C++?
« on: September 11, 2010, 10:20:45 am »
Interesting: http://blog.mozilla.com/nnethercote/2010/09/10/another-go-at-language-design/
I'd say that's a pretty ambitious goal for Go engineers...
It also makes the advantage of scripting languages(just run instead of first compile then run) much smaller.
Quote
Compile times of Go programs are small. This is because the compiler doesn’t need to know about transitive dependencies between packages (their name for modules). (...) He said with a completely straight face that their goal was to have a 1,000,000x speed-up over C++ for the compilation time of large programs, though they’d probably be satisfied with 100,000x.
I'd say that's a pretty ambitious goal for Go engineers...
It also makes the advantage of scripting languages(just run instead of first compile then run) much smaller.
19
Function Peer Review / Progressions
« on: September 10, 2010, 06:22:21 pm »
I've made two scripts for progress management: one for linear progress and one for parabolic progress.
The concept for linear progress is very simple. You define a "initial state" and "intended state", and then a "progression position".
It will then linearly go from one to another.
A simple example would be in the step event:
In the code above, the object x would go from 10 to 20, linearly, and take 1000 steps to do it.
Another piece of code I wrote are parabolic progressions. In this case, there is also an initial state and a "position", but instead of "intended state" there is a "middle state", that is, the state of the progression when position is 0.5.
In my code, I use this for jumps.
I would also like to have cubic progressions, which would behave very similarly to linear progressions.
Anyway, here are the scripts:
linear_progression.gml (initial, final, t)
parabolic_progression.gml (initial, middle, t)
Hope this is useful for the rest of you.
The concept for linear progress is very simple. You define a "initial state" and "intended state", and then a "progression position".
It will then linearly go from one to another.
A simple example would be in the step event:
Code: [Select]
while (self.iter < 1000) {
self.iter += 1;
self.x = linear_progression(10, 20, self.iter / 1000);
}
In the code above, the object x would go from 10 to 20, linearly, and take 1000 steps to do it.
Another piece of code I wrote are parabolic progressions. In this case, there is also an initial state and a "position", but instead of "intended state" there is a "middle state", that is, the state of the progression when position is 0.5.
In my code, I use this for jumps.
I would also like to have cubic progressions, which would behave very similarly to linear progressions.
Anyway, here are the scripts:
linear_progression.gml (initial, final, t)
Code: [Select]
return argument0 + (argument1 - argument0) * argument2;
parabolic_progression.gml (initial, middle, t)
Code: [Select]
var a;
a = 4 * (argument0 - argument1);
return a * argument2 * argument2 - a * argument2 + argument0;
Hope this is useful for the rest of you.
20
General ENIGMA / ENIGMA on the iPhone - Once again legal?
« on: September 09, 2010, 09:37:51 am »
Apple relaxes restrictions on iOS app code, iAd analytics
It appears that Apple is loosening some of its most controversial iOS development rules.
Although the article doesn't seem to show the new language of the agreement, it is a good sign for ENIGMA developers who hope to see their games on iPhone in the future.
It appears that Apple is loosening some of its most controversial iOS development rules.
Although the article doesn't seem to show the new language of the agreement, it is a good sign for ENIGMA developers who hope to see their games on iPhone in the future.
21
Proposals / ENIGMA Wiki
« on: September 08, 2010, 09:53:30 am »
I was wondering, just like there is wiki.yoyogames.com, there could be a wiki for ENIGMA development, including detailed documentation of the multiple ENIGMA(and GM) functions.
Documentation really helps development.
Documentation really helps development.
22
Issues Help Desk / Needed ENIGMA functions
« on: September 06, 2010, 05:28:48 pm »
I'm trying ENIGMA and I've noticed several functions aren't available. I'm curious regarding whether the following functions are just not-yet-implemented or if any of those won't ever be:
object_get_parent
instance_change
instance_place
I could easily implement/contribute instance_place, but I'll need a working implementation of object_get_parent for that...
BTW: Regarding compile syntax errors, ENIGMA says which errors occur and in what files, but not in which line. You really should address this.
object_get_parent
instance_change
instance_place
I could easily implement/contribute instance_place, but I'll need a working implementation of object_get_parent for that...
BTW: Regarding compile syntax errors, ENIGMA says which errors occur and in what files, but not in which line. You really should address this.
23
General ENIGMA / GML
« on: September 04, 2010, 09:47:34 am »
In my understanding, GML only has a two data types: strings and reals. Most variables, such as rooms, objects, etc. are in fact IDs(reals). surface_create does not return a surface, but rather the ID of a surface. The same applies to stacks, etc.
I'm curious about something in the ID system. Are all IDs completely unique or just unique to that data type? (there can be no more than one single stack with any given ID, but can a stack and a queue have the same ID? Same to instances, objects, etc.)
I'm curious about something in the ID system. Are all IDs completely unique or just unique to that data type? (there can be no more than one single stack with any given ID, but can a stack and a queue have the same ID? Same to instances, objects, etc.)
24
General ENIGMA / Windows OpenGL detection
« on: July 17, 2010, 03:39:58 pm »
I've created a simple command line Windows application do detect which OpenGL version is installed and what extensions are available.
I called it "glversion".
To use it, just run it from the command line. You'll get as output something like this:
With this application, you can realize how awful your GPU truly is(no FBO ).
I mean, OpenGL 1.4! We're in OpenGL FOUR now and the GPU comes with OPENGL 1.4!!?
I guess people are right when they say Intel is garbage when it comes to graphics.
Anyway, I hope you find this useful.
I called it "glversion".
Code: [Select]
/*
The MIT License
Copyright (c) 2010 Luís Reis <luiscubal@gmail.com>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
*/
#include <windows.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <stdio.h>
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
return DefWindowProc(hwnd, msg, wParam, lParam);
}
const wchar_t g_szClassName[] = L"myWindowClass";
int main(int argc, char* argv[])
{
WNDCLASSEX wc;
HWND hwnd;
MSG Msg;
//Step 1: Registering the Window Class
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_OWNDC;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = GetModuleHandle(NULL);
wc.hIcon = 0;
wc.hCursor = 0;
wc.hbrBackground = 0;
wc.lpszMenuName = NULL;
wc.lpszClassName = g_szClassName;
wc.hIconSm = 0;
if(!RegisterClassEx(&wc))
{
printf("Class registering failed\n");
return 1;
}
// Step 2: Creating the Window
hwnd = CreateWindowEx(
WS_EX_CLIENTEDGE,
g_szClassName,
L"The title of my window",
WS_CLIPSIBLINGS | WS_CLIPCHILDREN,
CW_USEDEFAULT, CW_USEDEFAULT, 240, 120,
NULL, NULL, GetModuleHandle(NULL), NULL);
if(hwnd == NULL)
{
printf("Window creation failed!\n");
return 1;
}
HDC hdc;
HGLRC hrc;
if (!(hdc = GetDC(hwnd))) {
printf("Could not create drawing context\n");
return 1;
}
static PIXELFORMATDESCRIPTOR pfd= {
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,
32,
0, 0, 0, 0, 0, 0,
0,
0,
0,
0, 0, 0, 0,
16,
0,
PFD_MAIN_PLANE,
0,
0, 0, 0
};
GLuint PixelFormat;
if (!(PixelFormat=ChoosePixelFormat(hdc,&pfd)))
{
printf("Could not find pixel format\n");
return 1;
}
if(!SetPixelFormat(hdc,PixelFormat,&pfd))
{
printf("Could not set pixel format\n");
return 1;
}
if (!(hrc = wglCreateContext(hdc))) {
printf("Could not create OpenGL context\n");
return 1;
}
wglMakeCurrent(hdc, hrc);
const char* vendor = (const char*) glGetString(GL_VENDOR);
const char* renderer = (const char*) glGetString(GL_RENDERER);
const char* version = (const char*) glGetString(GL_VERSION);
const char* extensions = (const char*) glGetString(GL_EXTENSIONS);
printf("Vendor: %s\nRenderer: %s\nVersion: %s\nExtensions: %s\n", vendor, renderer, version, extensions);
printf("OpenGL Error: %s\n", gluErrorString(glGetError()));
return 0;
}
To use it, just run it from the command line. You'll get as output something like this:
Code: [Select]
Vendor: Intel
Renderer: Intel 945GM
Version: 1.4.0 - Build 8.14.10.1930
Extensions: GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_blend_color GL_EXT_abgr GL_EXT_texture3D GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_cull_vertex GL_SGIS_texture_edge_clamp GL_SGIS_generate_mipmap GL_EXT_draw_range_elements GL_SGIS_texture_lod GL_EXT_rescale_normal GL_EXT_packed_pixels GL_EXT_separate_specular_color GL_ARB_multitexture GL_EXT_texture_env_combine GL_EXT_bgra GL_EXT_blend_func_separate GL_EXT_secondary_color GL_EXT_fog_coord GL_EXT_texture_env_add GL_ARB_texture_cube_map GL_ARB_transpose_matrix GL_ARB_texture_env_add GL_IBM_texture_mirrored_repeat GL_EXT_multi_draw_arrays GL_NV_blend_square GL_ARB_texture_compression GL_3DFX_texture_compression_FXT1 GL_EXT_texture_filter_anisotropic GL_ARB_texture_border_clamp GL_ARB_point_parameters GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_EXT_texture_compression_s3tc GL_ARB_shadow GL_ARB_window_pos GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_ARB_vertex_program GL_ARB_fragment_program GL_EXT_stencil_two_side GL_ARB_vertex_buffer_object GL_EXT_texture_lod_bias GL_NV_texgen_reflection GL_ARB_depth_texture GL_WIN_swap_hint
OpenGL Error: no errors
With this application, you can realize how awful your GPU truly is(no FBO ).
I mean, OpenGL 1.4! We're in OpenGL FOUR now and the GPU comes with OPENGL 1.4!!?
I guess people are right when they say Intel is garbage when it comes to graphics.
Anyway, I hope you find this useful.
25
General ENIGMA / APIs & Articles worth keeping in mind
« on: July 17, 2010, 08:26:09 am »
This is my collection of important APIs and articles useful when developing games or game engines.
APIs:
SDL
SFML
OpenGL
Direct3D
DevIL
OpenAL
libvorbis
Bullet Collision Detection & Physics Library
Lua
V8 JavaScript library
GStreamer
Articles and tutorials:
http://www.swiftless.com/
http://www.gamedev.net/reference/articles/article2008.asp
http://www.gamedev.net/reference/articles/article2031.asp
http://www.gamedev.net/reference/articles/article2003.asp
http://www.gamedev.net/reference/articles/article709.asp
http://www.gamedev.net/reference/articles/article2251.asp
http://code.google.com/intl/pt-PT/apis/v8/get_started.html
http://code.google.com/intl/pt-PT/apis/v8/embed.html
Incomplete list, might add more later. Also, feel free to suggest articles you fell are relevant.
APIs:
SDL
SFML
OpenGL
Direct3D
DevIL
OpenAL
libvorbis
Bullet Collision Detection & Physics Library
Lua
V8 JavaScript library
GStreamer
Articles and tutorials:
http://www.swiftless.com/
http://www.gamedev.net/reference/articles/article2008.asp
http://www.gamedev.net/reference/articles/article2031.asp
http://www.gamedev.net/reference/articles/article2003.asp
http://www.gamedev.net/reference/articles/article709.asp
http://www.gamedev.net/reference/articles/article2251.asp
http://code.google.com/intl/pt-PT/apis/v8/get_started.html
http://code.google.com/intl/pt-PT/apis/v8/embed.html
Incomplete list, might add more later. Also, feel free to suggest articles you fell are relevant.
26
Off-Topic / Perfect low-level game framework
« on: July 02, 2010, 01:43:55 pm »
Ok, so there's like ten million APIs for coding games.
However, none of them are good enough.
The reason is this: When coding games, no system is isolated. Integration is essential.
So, I present - my own perfect imaginary low-level game framework:
Some basic principles
1. In modules, so if you don't need Internet access, it wouldn't waste space
2. Although unrelated modules are independent, modules obviously can have dependencies. So, for instance, the Video and Image modules could depend on the Graphics module
3. The API would be object-oriented. It could be written in C, provided that bindings available for object-oriented languages are available.
4. The API must support at least the following file formats: BMP, PNG, WAV, OGG and OGV. Other formats can be supported, such as MIDI, MP3 and WEBM, but are optional.
5. Rendering to window, to control and to image(texture?) must be supported.
6. Cross-platform: WinAPI, WPF, Xlib, GTK+, Qt, Cocoa.
7. The audio API must have optional streaming(but also the option of loading all at once), playing(once or looping), pausing, resuming, stopping, fading in, fading out, mixing, volume control, ability to select only parts of the sound to be played, capacity of detecting how long the sound file is, panning, and - very important - seeking(both in streaming and non-streaming). SDL_Mixer has no streaming support in some cases.
8. The audio API would provide both 2D and 3D audio support.
9. The video API would also provide playing with optional looping, pausing, resuming, stopping, seeking, etc.
10. I haven't used shaders and audio post-effects in the past, but apparently they are important, so the API should provide first-class support for these.
11. Video and animated images should have first class support.
12. The API must be designed for extreme efficiency and speed, and take advantage of hardware acceleration if available.
So, a simple hello world in my perfect API(in C++):
At this point, the API is quite conventional.
What makes it different?
1. Contexts: Having many contexts at the same time. Then one'd just apply the functions(begin, end, etc.) to a different context and it'd "just work". OpenGL isn't very context-friendly, since you can only have one active context at any given time.
2. Unification: Using base classes such as Drawable, the same functions could be applied to colors, static images, animated images, text, other graphical contexts and even movies. In OpenGL, this part is notably bad. Even with existent libraries available(such as DevIL). Try rendering a GStreamer movie in an OpenGL cube. Really, I'll be very interested in example code if you can show me.
3. Render to textures: Because of contexts and unification, this is as simple as rendering to the screen.
4. Video as just another resource: Ability to pick a video and just render it to a cube like it was a texture is important.
5. Draw context to context: A variant of render to textures.
This is my imaginary perfect low-level game API. If something like this already exists, I'd be happy to use it. It could be in C++, Java or .NET provided that it had all the simplicity and features I described.
However, none of them are good enough.
The reason is this: When coding games, no system is isolated. Integration is essential.
So, I present - my own perfect imaginary low-level game framework:
Some basic principles
1. In modules, so if you don't need Internet access, it wouldn't waste space
2. Although unrelated modules are independent, modules obviously can have dependencies. So, for instance, the Video and Image modules could depend on the Graphics module
3. The API would be object-oriented. It could be written in C, provided that bindings available for object-oriented languages are available.
4. The API must support at least the following file formats: BMP, PNG, WAV, OGG and OGV. Other formats can be supported, such as MIDI, MP3 and WEBM, but are optional.
5. Rendering to window, to control and to image(texture?) must be supported.
6. Cross-platform: WinAPI, WPF, Xlib, GTK+, Qt, Cocoa.
7. The audio API must have optional streaming(but also the option of loading all at once), playing(once or looping), pausing, resuming, stopping, fading in, fading out, mixing, volume control, ability to select only parts of the sound to be played, capacity of detecting how long the sound file is, panning, and - very important - seeking(both in streaming and non-streaming). SDL_Mixer has no streaming support in some cases.
8. The audio API would provide both 2D and 3D audio support.
9. The video API would also provide playing with optional looping, pausing, resuming, stopping, seeking, etc.
10. I haven't used shaders and audio post-effects in the past, but apparently they are important, so the API should provide first-class support for these.
11. Video and animated images should have first class support.
12. The API must be designed for extreme efficiency and speed, and take advantage of hardware acceleration if available.
So, a simple hello world in my perfect API(in C++):
Code: [Select]
#include <awesome-api/all>
using namespace awesome::Core;
using namespace awesome::Graphics;
using namespace awesome::Image;
using namespace awesome::Fonts;
int main(int argc, char* argv[]) {
GameWindow window("Hello World!", 800, 600, 32, false); //Title, Width, Height, Bpp, Fullscreen
WindowGraphicsContext ctx(window);
ctx.EnableDoubleBuffering(true);
Image img("image.png", false); //Second parameter means explicitly disable support for animations(APNG, in this case) even if they are supported
Matrix& projection = ctx.ProjectionMatrix();
projection.ToIdentity();
projection.Multiply(OrthographicMatrix(0.0f, 800, 600, 0.0f, -1.0f, 1.0f));
//To be honest, I mostly copied the two lines above from an SDL+OpenGL tutorial
ctx.TransformMatrix().ToIdentity(); //Reset all transformations
//Here I'll make it similar to OpenGL because not everything in OpenGL sucks
ctx.Begin();
//We could use the long way, but the API would include some utilities to simplify common usages
//An even more simplified version(DrawImageRect) would be provided, taking away the whole "BottomLeft" stuff
//but in this case, this is provided to show the flexibility of the API.
DrawUtils::DrawRect(ctx, img.BottomLeft(), img.BottomRight(), img.TopRight(), img.TopLeft(), Rectangle(Vertex3(0,0,0), Vertex3(800, 600,0)));
ctx.End();
ctx.SwapBuffers();
ctx.Dispose();
window.Dispose();
return 0;
}
At this point, the API is quite conventional.
What makes it different?
1. Contexts: Having many contexts at the same time. Then one'd just apply the functions(begin, end, etc.) to a different context and it'd "just work". OpenGL isn't very context-friendly, since you can only have one active context at any given time.
2. Unification: Using base classes such as Drawable, the same functions could be applied to colors, static images, animated images, text, other graphical contexts and even movies. In OpenGL, this part is notably bad. Even with existent libraries available(such as DevIL). Try rendering a GStreamer movie in an OpenGL cube. Really, I'll be very interested in example code if you can show me.
3. Render to textures: Because of contexts and unification, this is as simple as rendering to the screen.
4. Video as just another resource: Ability to pick a video and just render it to a cube like it was a texture is important.
5. Draw context to context: A variant of render to textures.
This is my imaginary perfect low-level game API. If something like this already exists, I'd be happy to use it. It could be in C++, Java or .NET provided that it had all the simplicity and features I described.
27
Google's V8 embedding API for C++ rocks. Honestly, it'll be really competitive with Lua, although I don't have benchmarks to compare them in terms of speed.
The garbage collection API is a bit strange. I'm not yet fully sure what's the difference between a common Handle<T> and a Local<T> handle.
It also took me a bit to get used to the concept of ObjectTemplate, how to handle functions-as-constructors and I still haven't figured out how to change the prototype of primitive types(such as adding methods to strings).
Also, I like the use of static New methods instead of ordinary C++ constructors. It solves a number of garbage collector issues.
In just two days, I went from zero to having a working CommonJS Modules 1.0(slighly modified) implementation in V8(with the help of zlib).
If anyone is considering embedding scripts in your projects(games or otherwise), V8 is definitively worth considering. At least on Linux, it's really easy to setup(#include "v8.h" with -lv8). I'm guessing Windows and Mac OS X users shouldn't have too much trouble either.
V8 also has the reputation of being ultra-fast. If anyone is interested, the following pages should help:
http://code.google.com/apis/v8/get_started.html
http://code.google.com/apis/v8/embed.html
http://bespin.cz/~ondras/html/namespacev8.html
http://v8.googlecode.com/svn/trunk/samples/
The API is very easy to use and is actually making me consider some modifications to a language VM I'm currently designing.
The garbage collection API is a bit strange. I'm not yet fully sure what's the difference between a common Handle<T> and a Local<T> handle.
It also took me a bit to get used to the concept of ObjectTemplate, how to handle functions-as-constructors and I still haven't figured out how to change the prototype of primitive types(such as adding methods to strings).
Also, I like the use of static New methods instead of ordinary C++ constructors. It solves a number of garbage collector issues.
In just two days, I went from zero to having a working CommonJS Modules 1.0(slighly modified) implementation in V8(with the help of zlib).
If anyone is considering embedding scripts in your projects(games or otherwise), V8 is definitively worth considering. At least on Linux, it's really easy to setup(#include "v8.h" with -lv8). I'm guessing Windows and Mac OS X users shouldn't have too much trouble either.
V8 also has the reputation of being ultra-fast. If anyone is interested, the following pages should help:
http://code.google.com/apis/v8/get_started.html
http://code.google.com/apis/v8/embed.html
http://bespin.cz/~ondras/html/namespacev8.html
http://v8.googlecode.com/svn/trunk/samples/
The API is very easy to use and is actually making me consider some modifications to a language VM I'm currently designing.
28
Off-Topic / WebM released
« on: May 19, 2010, 12:16:18 pm »
Google has just released WebM, their solution to HTML5 video.
WebM is a combination of previously existent technologies, such as the Vorbis audio codec, with Google's On2 VP8 video codec.
Google wanted a patent-free format and they managed to get a healthy list of supporters, including:
- Themselves (obviously, they do have YouTube and Chrome, both of which have experimental support for it)
- Adobe (which will add it to Flash)
- Mozilla (which already has a Firefox nightly with it)
- Opera (which already has an Opera nightly with it)
- AMD
- ARM
- MIPS
- NVidia
- Texas Instruments
and lots of other guys nobody ever heard of.
Basically, they have lots of hardware support, and lots of software player makers(Chrome, Flash, Firefox and Opera).
The only important players missing from the list are Intel, Microsoft and Apple. Not sure about Intel, but MS and Apple are part of the MPEG-LA, supporters of H.264 and developers of two browsers - IE and Safari.
WebM just turned on the heat on the HTML5 video codec debate once again.
http://webmproject.blogspot.com/
What do you think? Will Apple and Microsoft jump in? Will someone claim patents over Google's(On2) work?
WebM is a combination of previously existent technologies, such as the Vorbis audio codec, with Google's On2 VP8 video codec.
Google wanted a patent-free format and they managed to get a healthy list of supporters, including:
- Themselves (obviously, they do have YouTube and Chrome, both of which have experimental support for it)
- Adobe (which will add it to Flash)
- Mozilla (which already has a Firefox nightly with it)
- Opera (which already has an Opera nightly with it)
- AMD
- ARM
- MIPS
- NVidia
- Texas Instruments
and lots of other guys nobody ever heard of.
Basically, they have lots of hardware support, and lots of software player makers(Chrome, Flash, Firefox and Opera).
The only important players missing from the list are Intel, Microsoft and Apple. Not sure about Intel, but MS and Apple are part of the MPEG-LA, supporters of H.264 and developers of two browsers - IE and Safari.
WebM just turned on the heat on the HTML5 video codec debate once again.
http://webmproject.blogspot.com/
What do you think? Will Apple and Microsoft jump in? Will someone claim patents over Google's(On2) work?
29
General ENIGMA / ENIGMA on iPhone - Now legally impossible
« on: April 09, 2010, 04:18:47 pm »
Maybe some of you are waiting for ENIGMA to compile iPhone games? Are you?
iPhone terms&conditions previously were against interpreted/JIT applications. However, using C# was OK if you AOT it(ahead-of-time compiled it).
So maybe ENIGMA should be OK as long as Josh doesn't include V8? After all, ENIGMA *compiles* games...
The initial sentence is OK. However, the problem starts in:
This means, no C#, no Java, no Python, no Lua, no Flash, no HaXe, no ASM and... no GML.
ENIGMA translates hybrid GML/C++ to plain C++, which this now specifically forbids.
Maybe now you're saying: Hell, screw GML. I'll just use plain C++!
Well, first of all you'll have to find a way to skip Josh's parser and, in second place...
What happens to your objects? Your rooms? Are they originally written in C++? No.
So you'll have to manually position all your rooms' objects in a C++ file.
But wait, this gets better:
Lovely, heh?
So kiss your iPhone ENIGMA gaming hopes good bye.
Since Windows Phone 7 only allows .NET programming, that means the only smartphone ENIGMA can possibly ever run in is Android(maybe BlackBerry or Palm? I haven't looked into those two...)
iPhone terms&conditions previously were against interpreted/JIT applications. However, using C# was OK if you AOT it(ahead-of-time compiled it).
So maybe ENIGMA should be OK as long as Josh doesn't include V8? After all, ENIGMA *compiles* games...
Quote
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
The initial sentence is OK. However, the problem starts in:
Quote
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine(emphasis mine)
This means, no C#, no Java, no Python, no Lua, no Flash, no HaXe, no ASM and... no GML.
ENIGMA translates hybrid GML/C++ to plain C++, which this now specifically forbids.
Maybe now you're saying: Hell, screw GML. I'll just use plain C++!
Well, first of all you'll have to find a way to skip Josh's parser and, in second place...
What happens to your objects? Your rooms? Are they originally written in C++? No.
So you'll have to manually position all your rooms' objects in a C++ file.
But wait, this gets better:
Quote
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibitedSo, you can't even have some intermediate layer, such as create_room, etc.
Lovely, heh?
So kiss your iPhone ENIGMA gaming hopes good bye.
Since Windows Phone 7 only allows .NET programming, that means the only smartphone ENIGMA can possibly ever run in is Android(maybe BlackBerry or Palm? I haven't looked into those two...)
30
Off-Topic / The grand c++ vs everyone else debate
« on: April 06, 2010, 08:19:47 am »
I'm thinking that, if we're to discuss the whole C++ vs Java/C# issue, this might be a better place than the Announcements.
Does everyone else agree? (Or is that discussion over?)
Does everyone else agree? (Or is that discussion over?)