Please login or register.

Login with username, password and session length
Advanced search  

News:

IRC channel - server: waelisch.de  channel: #wme (read more)

Show Posts

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.

Messages - HCDaniel

Pages: 1 [2] 3 4 ... 11
16
WME Lite / Re: WMELite development version for Android
« on: July 29, 2016, 11:28:37 AM »
Hi,

I have published an update to the development app. Playback of .wav files is no longer broken and Targa graphics support has been added as I found it to be used in at least one game. A fallback .ttf font is now also available in case your game relies on that mechanism.

I also added initial (experimental) keyboard support. The engine can unfortunately not really "guess" when there's the right time to show an on-screen-keyboard, so there are 2 new methods "Game.StartTextInput(int)" and "Game.StopTextInput()" to be added to the scripts that expect to receive keyboard input. The parameter to "StartTextInput" is currently ignored, but if relevant, you can specify the desired screen y coordinate that should be "best visible" while the keyboard is shown. In the future the visible part of the game might be adjusted appropriately so that the specified coordinate is in the middle of the remaining screen area above the keyboard.

Please try it out and let me know what works/doesn't work!

17
WME Lite / Universal Windows Platform (UWP) demo
« on: June 07, 2016, 11:30:14 AM »
Hi,

I created a demo app for UWP and uploaded it into the store:

https://www.microsoft.com/en-us/store/games/wmelite-engine/9nblggh4wb5z

It is based on my branch of WMElite. Should work with both mouse & touch input.

I made a deviation to the user interface, a short click/touch will invoke the "look action", and a long mouse click/touch will show the overlay menu.

Source code is on bitbucket. Feedback welcome.

18
You can follow the instructions with VS2015, the upgrade wizard should apply the necessary changes when migrating the project.

19
WME Lite / WMELite development version for Android
« on: April 27, 2016, 12:31:23 PM »
Hi,

I have released a "development" Version of the WME Lite engine for Android on Google Play:

https://play.google.com/store/apps/details?id=org.deadcode.wmelite.development

If you just install & run, you will see the "Molly" actor only in an empty scene.

But if you connect your device to a PC and place a game onto the tablet (either packages or all the project's files, but please not both - I don't know what happens then), and then start the app, you might see your game running on Android.

The app is compiled from my WME Lite branch and includes the script compiler. If you copy all your game files, make sure not to copy the package folders, only the content. You can easily check this - the "default.game" file should be in the root folder of your storage afterwards. If it is in a subfolder, it won't work.

The changes from my branch should not have too big impact. I'm using SDL_Mixer instead of BASS (to avoid cost of a license), and I have stripped down the FreeImage library, so it could be that some file types are not supported. MP3 files won't play, for instance, only ogg. I don't remember whether I kept .wav files in. Image support is also limited to .png .jpg and .gif.

The app tries to "guess" the folder where the packages or the game files were placed. Unfortunately manufacturers have a lot of freedom there, so I can't guarantee that the folder you place your files into will be found. (In case you know your internal folder name just let me know - I can safely expand the list.) If you know your way with the Android SDK, you can also use the "adb" command line tool to copy ("push") files onto the device. Although highly discouraged, I have not found any device yet that does not handle "/mnt/sdcard/" as target folder - even if mapped to sth. different internally.

Depending on how you left the app (exiting, switching to a different one, just exiting to home screen) it might not always pick up your latest changes to the files & packages. Make sure to remove the app from the "recent apps" list then.

Some settings can be modified with a "settings.xml" in the root folder (e.g. next to your packages resp. files). I suggest to use sth. like this for a start:

Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<Settings>
  <Debug>
    <DebugMode>0</DebugMode>
    <LogWriteMode>0</LogWriteMode>
  </Debug>
  <Font>
    <FontAlphaHack>1</FontAlphaHack>
  </Font>
  <Scaling>
    <UpScalingStepping>0</UpScalingStepping>
    <DownScalingStepping>0</DownScalingStepping>
  </Scaling>
  <Rendering>
    <PixelPerfect>0</PixelPerfect>
  </Rendering>
</Settings>

You can change the "DebugMode", "LogWriteMode" and "PixelPerfect" options as you like (just set those that you need to "1").

This way you can easily test for yourself how your game would work on a touch platform. All events are "left mouse button" events, and you will unlikely hit coordinates exactly.

I hope this helps if you "just want to know how a game looks on a touch platform", and with the script compiler available, you can even try out things fast.

If you experience an app crash, please report it (Android will ask you whether to report or not, please do!). But if something else doesn't work, I can only help you if you know your way with the "adb" command line and send me the log output ("adb logcat").

For iOS I doubt that the same thing is possible. I have no idea how such a "development app" could pass app review, and I have no idea how to supply the files separately to the app.

Have fun!

20
WME Lite / Question about CBGame::UnregisterObject
« on: March 07, 2016, 08:38:49 PM »
Hi Mnemonic,

I'm experiencing the same thing that happened here: http://forum.dead-code.org/index.php?topic=4797.0 with WMElite.

Do you know whether the fix you did back then made it into WME lite?

I looked into the code and am trying to understand what happens. In my case, a window is unloaded (with Game.UnloadObject) shortly after a call to Game.SaveGame.
The crash happens shortly after load, when the Game.UnloadObject command is reached, because the window object somehow refers(?) to/is casted(?) to/contains(?) an "CScValue" object, and the "InvalidateValues" method is called, which tries to call "IsNative()", and that one crashes because "if(m_Type==VAL_VARIABLE_REF)" is true but m_ValRef is NULL for one object of the list of instances. (As far as I understand the situation.)

I have no idea how it can happen that an CScValue object can have the m_Type field set to VAL_VARIABLE_REF but no valid m_ValRef, at least after load. Can you help me out (once again)?

Regards,

Daniel

21
WME Lite / Re: WME lite crash report support
« on: March 04, 2016, 07:59:49 AM »
Thanks a lot Mnemonic! I just tested it with your original crash report dll :) This is cool!

22
Technical forum / Re: Strange artifact on scaled png
« on: March 03, 2016, 09:13:11 AM »
Is this happening with WME or WME lite? And does enabling resp. disabling the "pixelperfect rendering" option in WME lite make a difference?

We saw similar issues (not the same issue exactly though) with WME lite on Windows using Direct3D. OpenGL behaved better on this, but had other issues. Finally we kept Direct3D as default.



23
WME Lite / WME lite crash report support
« on: March 03, 2016, 09:08:38 AM »
Hi Mnemonic,

I want to use your crash report solution from WME for WME lite. I have not gotten very far yet, but I already see an issue that I fail to understand.

The extra code you use to catch the crashes:

Code: [Select]
#ifndef _DEBUG
__try
{
#endif
if(!CBPlatform::Initialize(Game, hInstance, hPrevInstance, lpszCmdLine, nCmdShow))
return FALSE;
#ifndef _DEBUG
}
__except(CBPlatform::HandleCrashReport(Game, GetExceptionInformation()))
{
return FALSE;
}
#endif

is not compiling just like that for me. If I leave the "Exception handling" settings as they are in WME (/EHsc) or with SEH (/EHa), I get an error about "__try/__except cannot be used because the enclosed code requires finalizers" (error line from my memory, I did not capture it properly). And obviously there will be another error (actually a warning, but I think a reasonable one) like "exceptions used but unwinding disabled" if I compile without exception handling - which I probably do not want in the first place.

My only alternative would be to look at this project

http://crashrpt.sourceforge.net/

but this looks like overhead to me, considering that there is already a crash reporting functionality in WME that just needs porting.

Can you give me a hint on this one?

Regards,

Daniel

24
The fix also made it into "normal" WME:

https://bitbucket.org/MnemonicWME/wme1/commits/0e420c43be4fa45830778554a467b9ca88eaa8c0

I almost believe its the same bug, however, we saw it with "normal" talk also, not just "talkAsync". It should occur every time that the actor turns to a direction that is "next" to the one he was talking to previously, without walking in between, i.e. from UP to either UP_LEFT or UP_RIGHT. Then, incorrectly, the old UP direction (which was cached) is used.

Let me check if I still have a working setup to compile "normal" WME. Then I can upload an executable in the next days for you to test.

25
Could be the engine bug I was facing some time ago. Talk anim cache was not always invalidated properly. Could be reproduced if you had several entities to talk to, all with the same point for the actor (so the actor will not walk to a new point when a different entity is clicked) but with different directions to talk to.

I committed a fix some time ago:

https://bitbucket.org/MnemonicWME/wmelite/commits/dc23b38b043ccf0fd91917039227e1e04f49bd7c

So if your scenario triggers this bug, you are doing everything correct usage-wise.

26
WME Lite / Proof of concept: script compiler library for Linux
« on: January 07, 2016, 09:39:58 AM »
Hi,

I managed to get the script compiler library to integrate into WME Lite on Linux (32 bit tested so far). The code needed only minor adaptations. Looks like this can be achieved for the other supported platforms as well (and then cleaned up and merged into the original sources and so on).

My question: Is there a need from anybody for such a solution, so that it makes sense to come from a "proof-of-concept" dirty hack to a clean implementation?

I was thinking about having this available for Android, to be able to develop & test scripts without having to compile packages first. I wonder though whether there is a reasonable work flow that benefits from this solution.

27
WME Lite / Re: 64 bit apps?
« on: December 24, 2015, 09:51:03 AM »
Theora is currently not a priority for me as we do not need it for our game. I am busy with engine adaptations for ios and android at the moment.

28
Game announcements / Krabat a potajnstwo serbskeho krala
« on: November 23, 2015, 11:54:30 AM »
Hi,

after 6 years of work we released our WME (lite) based adventure "Krabat a potajnstwo serbskeho krala" (Krabat and the mystery of the sorbian king). It is an old-school point&click adventure, loosely based on the legend of Krabat, which is famous in our region.

The game is in sorbian and german only, unfortunately no english version.

Visit http://www.rapaki.de for more information. And of yourse, you can order a copy here: https://shop.sorben.com/

29
WME Lite / Re: Android, how to set up project?
« on: November 09, 2015, 01:32:13 PM »
Just send me your .dcp files (I assume that's what you meant) and the desired canonical name of your app, then I can send you a "debug APK" for testing.

30
WME Lite / Re: Android, how to set up project?
« on: November 07, 2015, 03:06:51 PM »
That I can't really tell. Android devices come in a variety of (native) resolutions. Whatever looks good on one device, might look bad on another. You need to check several devices. The Android emulator allows to configure screen size and resolution (not sure if 100% freely, but you have several options), so you can check there as well.

For our project we historically decided for 1024x600. That looks good on a variety of devices, independent of their native resolution (wmelite will scale the picture to fullscreen, keeping only the acpect ratio - thus a ratio of around 16:9 should be used to keep the black bars at the side of the screen small).

More important was the use of the "pixelperfect" rendering option in the "settings.xml", as we could not afford inaccuracies of graphics when they were all individually scaled when being drawn. That option is on one hand very memory intensive (you need a back buffer of your graphics in original resolution and depth in memory additionally), but avoids scaling artifacts between individual graphics. It depends on how you arrange your graphics, whether you actually need this option. It should be kept off if not necessary.

Pages: 1 [2] 3 4 ... 11

Page created in 0.288 seconds with 23 queries.