Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

61

WME Lite / Re: 64 bit apps?

« on: July 08, 2015, 08:28:08 AM »

In case you do not need theora playback and can live with SDL mixer instead of BASS for audio, you could try my fork. I hope to have a working ios simulator and 64 bit libs available in a couple of weeks, depending on my progress. I can't test the device libraries yet (lack of devices and membership in the paid Apple developer program). I don't know if that would fit your timeline.

62

WME Lite / Re: 64 bit apps?

« on: July 08, 2015, 06:59:03 AM »

No, I don't think so. The lite engine is running in 64 bit on Linux and Android at least, so I don't see a general 64 bit issue. The iOS platform just needs updated dependencies.

63

WME Lite / Re: 64 bit apps?

« on: July 08, 2015, 06:49:05 AM »

I believe the dependend libraries from bitbucket do not include support for 64 bit, thus it won't compile.

I am trying to generate Mac dependencies from my Android dependencies (which I already saw working on 64 bit), but only for my fork that does not include theora playback. I am making slow progress, because I'm totally new to the Mac environment.

64

Development / Re: MAc dependency update

« on: June 21, 2015, 03:01:36 PM »

Alternatively, could you publish your current projects for the dependencies? That would make life easier for the freetype and freeimage deps, which do not come with an xcode project per default.

65

Development / MAc dependency update

« on: June 08, 2015, 10:29:51 AM »

Hi Mnemonic,

do you have any plans to update the dependencies of osx and ios for wmelite, in order to support 64 bit? Looks like without that, no ios app would pass the conditions for publising in the store anymore.
I would especially be interested how to modify my SDL_mixer project to replace BASS on osx/ios.

Regards,

Daniel

66

WME Lite / Re: BASS vs. SDL Mixer

« on: April 30, 2015, 08:05:32 AM »

I hope you know how to compile code on a Mac, because I don't

At first you can try to compile the modified SDL mixer, just clone the repo here

https://bitbucket.org/hcdaniel/wmelite-dependencies-for-linux-and-android/overview

or download it here:

https://bitbucket.org/hcdaniel/wmelite-dependencies-for-linux-and-android/downloads

(download repository)

Then go into this directory:

dependencies/SDL_mixer/jni/

and try to compile using Xcode and the project files there.

If that works, combine the result with the dependencies found here:

https://bitbucket.org/MnemonicWME/wmelite/downloads

and then try to compile my wmelite fork:

https://bitbucket.org/hcdaniel/wmelite-rapaki-edition/overview

(again, clone the repo or download the code snapshot).

I don't know how to work with Xcode, so I cannot help you there. Maybe somebody else can if you run into problems.

Good luck!

67

WME Lite / Re: BASS vs. SDL Mixer

« on: April 28, 2015, 08:44:30 AM »

Hi!

I wonder if I could compile WME Lite to use SDL mixer instead of BASS library and in which platforms will be functional.

Any clues?

Thanks in advance!

I'm experimenting with a wmelite fork here:

https://bitbucket.org/hcdaniel/wmelite-rapaki-edition

and it has a compile time option to use SDL mixer instead of BASS. The SDL mixer has some patches (its not the "original one" anymore) which can be found here:

https://bitbucket.org/hcdaniel/wmelite-dependencies-for-linux-and-android/src/41d9d0b0857f59ef3f2b369b6f4386475eeeb38f/dependencies/SDL_mixer/?at=default

I did some spot checks on Windows, Linux and Android. Most of the functionality is there, but there will be bugs.

I'll clean it up and merge it into the original WME lite eventually.

Unfortunately I do not know how I can compile for Mac OS and iOS. No doubt that I won't have a chance to test things without the hardware, but if anybody knows how I can test that "things compile" without having a Mac, that would be great.

68

WME Lite / Re: Implement ad providers in android apps

« on: February 22, 2015, 11:12:08 AM »

Hi guys,

Suppose I make a free Android game, but I want to monetize via ads. Can it be done? Can I implement admob, leadbolt, airpush and similar ad providers in WME Lite? And if the answer is yes, how hard is it?

Thanks!

I guess so. I'm thinking about a "sort-of" generic scripting interface for controlling ads from wmelite. These would interact with the Java part of the engine (actually the Java part of SDL, which wmelite uses). In the Java world, the connection to the ad provider(s) can be done easily by yourself - which one you use, that would then be up to you.

It is not too difficult, but I haven't found any time yet to start working on this. The most difficult task is, from my point of view, to implement the JNI (Java Native Interface) part of the "wmelite scripting" <--> "ad provider" interface. You might use the existing callback implementations (for charset and other stuff) as reference.

I have implemented a first idea of said interface. It is currently tested with "AdBuddiz" only.

There are now 2 new scripting functions:

Code: [Select]

int Game.advertisementPrepare(String key, int number)
int Game.advertisementShow(String key, int number)

These are transparently passed from wmelite to the Java part of the app:

Code: [Select]


public int advertisementPrepare(String key, int number)
{
return 0;
}

public int advertisementShow(String key, int number)
{
return 0;
}


With these placeholders, you can (hopefully) add any advertisement provider to your game and control the displaying of ads via scripts.

In case of AdBuddiz, you can follow the instructions on their website, and then fill in the placeholders like this:

Code: [Select]


public int advertisementPrepare(String key, int number)
{
System.out.println("Query Advertisement SDK to prepare ads/check if ads prepared. Key=" + key + ",number=" + number + ".");

// place appropriate code here
if (AdBuddiz.isReadyToShowAd(act)) { // this = current Activity
                         return 1;
                }

return 0;
}

public int advertisementShow(String key, int number)
{
System.out.println("Instruct Advertisement SDK to show an ad. Key=" + key + ",number=" + number + ".");

// place appropriate code here
AdBuddiz.showAd(act);

return 0;
}


to have the 2 functions "isReadyToShowAd" and "showAd" controllable via scripts. (The example is not complete, I have omitted some other code changes, just to illustrate the part about controlling the advertisement by scripts.)

By making use of the additional parameters (which are unused in my example), you can do more complex operations (and hopefully use other ad providers as well).

69

WME Lite / Re: Any Linux developers out there?

« on: February 13, 2015, 09:01:10 AM »

All you need is to place the compiled ".dcp" files from your project into the same directory as the executable you just compiled.

70

WME Lite / Re: Implement ad providers in android apps

« on: February 12, 2015, 09:48:14 PM »

Hi guys,

Suppose I make a free Android game, but I want to monetize via ads. Can it be done? Can I implement admob, leadbolt, airpush and similar ad providers in WME Lite? And if the answer is yes, how hard is it?

Thanks!

I guess so. I'm thinking about a "sort-of" generic scripting interface for controlling ads from wmelite. These would interact with the Java part of the engine (actually the Java part of SDL, which wmelite uses). In the Java world, the connection to the ad provider(s) can be done easily by yourself - which one you use, that would then be up to you.

It is not too difficult, but I haven't found any time yet to start working on this. The most difficult task is, from my point of view, to implement the JNI (Java Native Interface) part of the "wmelite scripting" <--> "ad provider" interface. You might use the existing callback implementations (for charset and other stuff) as reference.

71

General Discussion / Re: Future of WME

« on: February 12, 2015, 09:37:57 PM »

The former DirectX SDK is now part of Windows SDK. Sadly, the Windows 8 / 8.1 SDK that ships with VS2013 dropped the D3DX utility library, which WME uses (thanks once again, Microsoft!). This article gives some hints on how to replace D3DX with alternatives, but it would probably require quite a lot of work.

Hmpf. I should have known that there is a catch At first it looked so promising...

72

WME Lite / Re: Any Linux developers out there?

« on: February 12, 2015, 10:00:52 AM »

There are Just download the bass linux .zip and then look into the "x64" subdirectory.

73

General Discussion / Re: Future of WME

« on: February 12, 2015, 07:50:40 AM »

Now that Microsoft gives out their compiler tools suite for free (unless you are a big company):

http://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

it could be easier to port all Windows based tools + engine to this recent toolset. It also ships with a DirectX SDK by default, so all the requirements to compile WME should be included. MFC is included as well, this was missing from the "express" editions and thus it was difficult to compile the tools without purchasing the compiler.

Anybody interested to "port" WME + Tools to the most recent compiler? Agreed, it won't make a difference right now, but maintenance might become easier, and in case sth. breaks on future Windows versions, it would be easier to fix.

74

WME Lite / Re: Any Linux developers out there?

« on: February 11, 2015, 09:52:05 PM »

Looks like your bass library doesn't match, i.e. it probably isn't 64 bit. At least the linker doesn't like the one you put in /usr/local/lib.

Can you cross-check this?

75

General Discussion / Re: Future of WME

« on: January 31, 2015, 12:47:31 PM »

I'd say that in order to answer the question, we need to look at the different components separately:

wmelite engine:
I would expect that this engine will receive enough attention and maintenance, so it will be functional for a long time. Especially the support for several platforms makes it an attractive choice for developing games with. I hope that by keeping it functional with all recent versions of libraries wmelite depends on, it won't happen that this engine suddenly stops working.

wme engine:
As long as Microsoft does not remove support for the APIs that wme uses, wme will work on windows. The same would be true for emulations (wine) on other platforms. I do not expect that removal of vital APIs in Windows happens soon. But there might be a scenario where wme stops working on a new Windows version, and then it could mean to invest some effort to get the engine to work again (using new compilers and newer library versions...).

tools:
similar to the wme engine. and when the tools stop working, new games won't be created, even if there was still an engine to run them.

I think Mnemonic did the right move to release all code under a permissive open source license. It increases the probability that somebody tries to fix things that become broken in the future.

I was wondering whether it would help if the Windows based programs are always updated to work with the newest DirectX version and the newest MS compiler. I was also wondering whether it would help to get at least the tools to compile with winelib. But either might involve quite some effort.