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 - sorlok_reaves

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
General ENIGMA / Re: Portable EXE is flagged as malware by Google Chrome
« on: August 04, 2014, 09:41:13 pm »
What about just uploading a zip (in addition to the EXE)? Many people are comfortable just downloading->extracting.

General ENIGMA / Portable EXE is flagged as malware by Google Chrome
« on: August 04, 2014, 09:12:14 pm »
Just FYI:

It's not really intrusive, since I was planing to do a reinstall anyway because of the problems with Lazarus, but if you want an answer more quickly...
I'll do it, give me an hour or so, to finish up a couple of things and then I'll give it a go.

Take your time, and do what you prefer. ENIGMA is working fine on my machine, so my only concern is for your setup.

Actually, if you want a less intrusive test, just do this:

  • Make a new user account on your system
  • Log in, download the latest master
  • Make a new, empty game in ENIGMA, add 1 object in 1 room, and compile.

If that works, then, yes, this is a caching problem.

Just to put things in perspective, I have only rarely run into issues with ENIGMA caching things improperly. In all cases, I deleted ~/.enigma and then re-ran the program and everything was fine. If you have properly backed up your system (and you are not worried about the consequences) you can try this.

Interesting. Does anyone know what this "timelines extension" is? I implemented my timelines improvements in the main source tree (Universal_System), and it seems like the one in "Extensions" doesn't do anything anyway.

So, just to reiterate, Universal_System/timelines_object* must exist for timelines to work. This is in mainline, and has nothing to do with the timelines extension. Also, the current master works, so try recompiling ENIGMA from that and re-building your code.

Ok, I've tracked this down a bit more. Basically, "object_locals" inherits from several items in series:
  • event_parent
  • object_collision
  • object_transform
  • object_graphics
  • object_timeline
  • ..etc.

At one point, I moved "timeline_running", etc., from object_graphics into a new class, object_timeline. So, for some reason, the executable you're using doesn't realize that.

Can you run this command for me? (I'm assuming you're on Linux, based on the output from a previous post)
Code: [Select]
ls -al ~/.enigma/.eobjs/Linux/Linux/Debug/Universal_System/ | grep time
The result should be "timelines_object.d" and "timelines_object.o".

If that doesn't register, you might want to clean the ~/.enigma/.eobjs directory. Can one of the other developers please recommend how to do this? (I always just delete ~/.enigma, but I've been told that's unsafe).

How bizarre; it looks like it's taking some code from the "old" timelines implementation, where I put these variables in a different place.

I'll have a look at my end and see if there's a messed up merge somewhere. Do you know what commit you're running?

General ENIGMA / Re: ENIGMA prototype bindings for SDL
« on: August 02, 2014, 02:39:58 pm »
Now however, some people just like SDL, and may like the fact that it works for all platforms for window management so it makes it less likely to break for just one. Another important thing to note is that you should move all of the SDL_GL stuff out to a bridge, it should not be in the platform folder because we can also build SDL with Direct3D and no platform should have graphics system specific code. All of these systems are supposed to be agnostic.

SDL can also do audio, although I haven't looked into it yet. Thanks for the advice on the Bridges/, now it makes sense what they are for.

I'll probably keep this on the back burner; I'd like to get it working eventually, but since the current system "just works" then it's not really a high priority.

General ENIGMA / ENIGMA prototype bindings for SDL
« on: August 01, 2014, 08:16:45 pm »
Good evening all,

Last week I started a prototype to get ENIGMA working with SDL platform bindings (code here). It was actually a lot easier than I thought, and we've got running games now:

I know that SDL is being bound, because the input's frozen. Whoops. :P

Anyway, so far this project was just for my own curiosity. I don't intend to continue it, but I wanted to check with you all first before abandoning it. Is this a wanted feature? Some benefits of SDL:
  • It has mostly the same code on all 3 platforms (glXSwapIntervalEXT notwithstanding).
  • SDL2 (which I am using) has support for Android. So... this makes things easier, right?
  • Even if you never use it, it's always nice to have a "backup", and right now most "Platforms" only have 1 option.
  • I have to fix all the xLib stuff anyway at some point, and switching to SDL might actually be easier.

The challenges:
  • A lot of the code in Platforms/ is actually not platform-specific, so I'd have to do a lot of refactoring.
  • This will inevitably lead to temporary breakage, which everyone (including me) hates.
  • Basically, I only want to put in the extra effort if people will use it.

Side-note: Input does actually work in my test scripts; I'm not 100% sure why it's frozen in Project Mario.

Developing ENIGMA / Re: Iji on ENIGMA
« on: July 26, 2014, 01:21:59 pm »
It looks very nice, thanks for sharing and for improving enigma also !  (Y)

You're welcome! Can't wait for the day when I can get a nice, playable beta version out to all you guys. :)

General ENIGMA / Re: Fun with imge_single
« on: July 26, 2014, 01:19:56 pm »
In this case, you're right; the obvious solution is to give image_single a special accessor, but then, you're also right that I have no interest in pulling this into upstream ENIGMA. :P

Makes sense. Anyway, thanks to everyone for the excellent feedback on this.

Developing ENIGMA / Re: Iji on ENIGMA
« on: July 25, 2014, 12:01:01 am »
New alpha release, with.... actual gameplay??? That's right.

Developing ENIGMA / Re: Android
« on: July 24, 2014, 12:45:21 pm »
I think it should be now possible to compile without Java boilerplate. Just like the link Rusky gave mentions. You can use GCC directly to compile for android.

That's only to compile the JNI part. To actually distribute an APK, you'll definitely need some Java source. Even the article mentions it, in the section "Simple Example"

Here, we can see:

  - The 'src' directory containing the Java sources for the sample Android project.

  - The 'jni' directory containing the native source for the sample, i.e. 'jni/hello-jni.c'

I am nearly certain that networking can't be done in JNI code (only Java), and I think Android Ad Services have to run in Java too. Also, the main JFrame must be created in Java.

Edit: This might be a better example; it's a tutorial on using SDL on Android. They basically provide all the boilerplate for you so that you can minimize the Java code you have to write (you just define an sdl_main method, which is in JNI).

Developing ENIGMA / Re: Android
« on: July 23, 2014, 11:17:18 pm »
Every Android project requires a small amount of Java boilerplate code. You'll typically create a normal Android project (using, say, the Eclipse plugin) with a "java" folder that contains Java code (Android Ad services, Network code, and the main window must go here) and then a "jni" folder (all your C++ code goes here). The "" file in the jni folder controls the building of the JNI code (although there are some annoying caveats).

In terms of Platform code, the most stable library is, to my knowledge, SDL. Android ports of SDL have been around forever, and it's part of upstream as of SDL 2.0. I think you'll have more luck adding an SDL backend then, say, fiddling with the Xlib code (I have seen Irrlicht running on Android, so it's not impossible to spin your own solution, but SDL has all the easy stuff like keymappings and touch gestures done).

At that point, you'll basically build the entire project with the generic "ndk-build" script that is distributed with the NDK. This handles all the compiler irregularities and environment variables, and I've never seen an Android project built any other way (i.e., using GCC directly). You will never have to edit "ndk-build".

Here is an example of a project that I know to be working on Android that uses SDL and native code; unfortunately, a lot of the linked page is explaining how to deal with Free Basic (which that project is using, but they also have some C code).

I'm not really an expert on the NDK (it's a huge pain, in my opinion), but let me know if you run into any particularly difficult issues and I'll do my best to help.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »