Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Posted on 03-16-13, 09:11 am in PillowShout's Prose and Code Depositorium (revision 2)
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 187/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Doors work by setting the tile underneath them to walls when the doors are closed, and floor when they're opened. The mapper literally hits a wall where the door is.

What I'd do is have the Dijkstra mapper detect doors and just pretend there's not a wall there. That just leaves the question, will the NPC open the door when getting there?


As for unreachability, if we pass our starting coordinates to the Dijkstra mapper we can have the mapper try to probe down the path it just created. If a target hotspot can't be reached, chances are good that the probe'll vaccilate between two spots or stop moving at all, which can be detected before returning the map.
Addendum: if the spot on our starting coordinates is still the Very High Number, it's probably unreachable. This came to mind on reflection because when I click-pathed around for testing my character didn't move at all. Because he was on a VHN and surrounded by VHN.


Edit: Appending the following to Dijkstra.UpdateWalls() fixes the first problem.
<blockquote>
foreach (var door in board.Entities.OfType<Door>().Where(d => !d.Locked))
        walls[door.YPosition, door.XPosition] = false;
</blockquote>
Both the Player and any BoardChar end up using Entity.Move() to take the actual steps, and Entity.Move() is the where doors are opened, so that was already covered.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 188/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Oh hey, you must be that one from Tumblr.

Assuming you got Mono to successfully install and know how to use a terminal, open one and find the directory you unpacked Noxico in. Then type <code style="background: #222"> mono Noxico.exe </code>. That ought to be enough. It certainly is when I run on Linux Mint, or on Windows when I want to bypass .Net and run in Mono instead. <small>hey that rhymed</small>

I know of no other way, though I'm sure there are. For example, since no executable on Linux or MacOS has a .EXE file extension, perhaps there's some system feature where you declare that .EXE files should be opened in Mono?

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 189/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Where'd you put it?

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 190/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
And where is the games folder?

For example, and banking on the fact that OS X is a *nix derivative like Linux, I have a copy in ~/Noxico. That is, it's in my home directory. To play, I open a terminal. It starts in the home directory. Therefore:

ls Noxico
mono Noxico.exe



I don't just program Noxico...
Posted on 03-16-13, 08:57 pm in Complete beginner wants to run game on Mac OSX [not a bug] (revision 1)
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 191/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Don't do that. Change to that directory and run Mono from there. Noxico is trying to run from whichever directory you started in, and thus can't find shit. That's what the "ls" in my example is for.


And now, I must go. Don't expect any fast replies until at least nine in the morning, local time.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 192/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Did you even try ls?

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 193/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
<h3>I have made a mess.</h3>
Let's clean it up.

Noxico has four kinds of file:
• .Net CLR Executable Assemblies: Noxico.exe itself. Not to be confused with regular Windows executables which are also .exe.
• .Net CLR Library Assemblies: Antlr3.Runtime.dll and Jint.dll. These can't be executed by themself.
• Regular library files: fmodex64.dll. These are different for each OS in that Windows uses foo.dll, Linux uses libfoo.so and MacOS uses foo.dylib (?)
• Data files: Noxico.mix. Doesn't contain any executable code whatsoever.

The first two can be used in Mono, on any OS you can run Mono on. Mono will automatically try to turn any references to foo.dll into libfoo.so or foo.dylib, if such an alternative can be found, unless foo.dll is a .Net CLR Assembly. Recent builds (I'm not sure about 0.1.14) can automatically disable sound if (lib)fmodex(64).(dll,so,dylib) can't load.

<code>ls</code> lists the items in the current directory (that is, the file system entity represented otherwiseby a folder). This is where I fucked up.
<code>cd</code> changes the current directory.

If <code>ls</code> claims that Antlr3.Runtime.dll is in the Noxico directory, but Noxico claims otherwise on startup, there's really only one logical explanation, especially with one of your earlier posts:
You're still not running Noxico from its own directory.


Your prompt and output may vary.
/> cd /Users/Your Name Here/Games

Games/> ls
Noxico.exe Noxico.mix Jint.dll Antlr3.Runtime.dll fmodex64.dll

Games/> mono Noxico.exe

Do not type "mono Noxico.exe" from any other directory, or type "mono /Users/Me/Games/Noxico.exe". CD to the directory Noxico is in and invoke it from there.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 194/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Like I explained in my attempt to clean up, Mono'll try to load fmodex64.dylib, since you're running on Mac. fmodex64.dll is worthless to you. I only have copies of the .dll and .so versions, but you might be able to get it from here.

To be honest, you might as well disable sound since you're not missing much, but I really don't feel like pointing out where the configuration file's at.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 195/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Y'know... I think the smartest thing to do here is to just give Eccleston here a prerelease of 0.1.15. It automatically disables sound instead of crashing if it can't load FMOD.

http://www.mediafire.com/?jzd8ubjomuqexgx

Make sure to remove the 0.1.14 you already have.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 196/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
The only place where shell32.dll is referred to is in the method where it tries to find where the Saved Games function is. This should only happen when actually running on Windows Vista or later. Why it detects Vista on a Mac is a mystery to me. I think there might be a logic error somewhere?

So here's another build that wraps all references to non-CLR DLL files into catch blocks: http://www.mediafire.com/?3k62nw67mz61sfl


I don't just program Noxico...
Posted on 03-18-13, 10:44 am in Internalizing the JS engine
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 197/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
At this moment, Noxico requires four files to start up:
• Noxico.exe, the main program
• Noxico.mix, the game data
• Jint.dll, the javascript interpreter
• Antlr3.Runtime.dll, which Jint uses for parsing

Sound support adds a few more:
&bull fmodex(64).dll (or libfmodex(64).so)
&bull Music.mix, technically optional
&bull Sound.mix, also technically optional

Now, I can't do this with FMOD, cos that's a regular library file, but I can and have internalized Jint and Antlr into the source code for a copy of Noxico. The end result is a single Noxico.exe that is the size of the regular one plus the two libraries, in one. Now you only need to account for two files to run:
• Noxico.exe, the main program
• Noxico.mix, the game data

Build times are still reasonable.

I think one of the effects would be less confusion like with Eccles.

This also fixes a potential performance problem in that Antlr uses the 2.0 runtime. Jint and Noxico use .Net 4.0. Internalizing them means that all parts use the same runtime.

The downside: if a new version of Jint is released, you can't just drop in a new copy of Jint.dll. (Antlr3 is outdated -- there's already an Antlr4 but Jint uses 3... for now.)

I don't just program Noxico...
Posted on 03-18-13, 12:08 pm in Complete beginner wants to run game on Mac OSX [not a bug] (revision 1)
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 198/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Frankly, I have no idea why that'd be. I've lost all idea regarding MacOS X, in fact.

Edit: running the latest build on Linux Mint is a bit slow at the beginning of gameplay because of surrounding boards being loaded. After that, it's all good on my end.

I don't just program Noxico...
Posted on 03-18-13, 07:18 pm in Internalizing the JS engine (revision 3)
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 199/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Performance is pretty much the same either way, except for the whole "no need to run .Net 2.0" part.

The main reason I can imagine too many scripts bogging down the game is that they all build, set up, and use their own Jint instances, every time RunScript is invoked, as opposed to ApplyMissions which builds one single Jint and uses it for each mission file in order. A similar problem occurs for each script block in scenes, but that's less noticable.

Having a single Jint for all BoardChars could be... problematic, in that aside from changing the identity globals (<code>this</code>, <code>thisEntity</code>) and the optional extra parameter (which can have any name on the JS side), other variables will leak across all BoardChars. On the other hand, nothing went wrong for ApplyMissions so far.

So what we could do to safely increase performance is to give each BoardChar its own Jint instance, preset once on initialization to have the correct <code>this</code> and <code>thisEntity</code> variables, along with all the types and methods, and only set the extra parameter when invoking RunScript. Because RunScript does a lot of stuff.

Edit: and replace all the Console.WriteLine() calls with a debug-only method in Program:
[System.Diagnostics.Conditional("DEBUG")]
static void WriteLine(string format, params object[] arg)
{
        Console.WriteLine(format, arg);
}
That might take a reasonable bite.

Update: BoardChar already have their own Jints, but RunScript still resets them every time. It's trivial to make them reset only the first time RunScript is invoked for a specific BoardChar, though...

I don't just program Noxico...
Posted on 03-19-13, 03:59 pm in Internalizing the JS engine
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 200/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
I've added a stopwatch to Game.Update, triggered every time it updates in Walkaround mode. In total I've timed 516 frames, in which the active/visible board is updated, along with its neighbors, and inactive boards are checked and flushed (there are none in this case). This includes copious timeskipping to see if there's any spikes when Jint is used. The impact is neglible compared to HD access.

../updateTime.txt

At frame #36, the neighbors were first accessed and needed loading, causing a spike of 3138177 ticks, or 1.20 seconds. The average time per frame is 46355 ticks, or .0046355 seconds.

Note that the Jint scripts were triggered near the end, but the largest spikes that weren't neighbor-loading occur much earlier.

I don't just program Noxico...
Posted on 03-19-13, 07:10 pm in Internalizing the JS engine (revision 1)
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 201/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Or if we're feeling particularly adventurous, multi-threaded board load requests!

Edit: or the more sensible and easier to implement variant of the above, a loading flag.

Every tick, the active board updates it neighbors. That means about eight other boards are requested from GetBoard(), which loads each of them if they're not already there. These GetBoard() requests are repeated for every tick -- the second time 'round, things are fast because the neighbors are already loaded. But loading all eight of them slows down the game! Instead, have GetBoard() set a flag when loading a board from disk, and only load if that flag is cleared. At the end of the tick, Game.Update() clears the flag again.

Now, only one neighbor is loaded for every tick, processing input between them instead of loading eight boards between inputs. In theory.

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 202/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
You realize, ofcourse, that "fix the keyboard issue by using mouse control" is not a fix. Anyway, I'm gonna meditate on an actual keyboard-based keyboard fix...

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 203/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Okay. The reason I use keyboard events is that it's (supposedly) portable. I could use GetKeyState to poll the actual keypress at this specific time, but that'd lock keyboard entry to Windows only. So I'm pretty limited there, and'll have to work from events... hmm...

As for the mouse, that's because you're not really supposed to change the window size while running (it drops the framerate) and the pixel-to-tile math assumes 1:1 scale.

I don't just program Noxico...
Posted on 03-20-13, 09:40 am in Exception type: EndOfStreamException
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 204/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Would you mind running the 0.1.15 I linked in the other thread?

I don't just program Noxico...
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 205/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
That's funny cos I'm not, and polling key state would actually bypass the timing problem we have now. Allow me to paint a picture:

When polling, you ask the OS "is this key down right about now?" when you need to know. Such as, checking if the player should move to the left. You get the keyboard state at that moment (or close enough, with the timescales in play here).

What Noxico does is that the OS and WinForms push keyboard events onto Noxico, which then puts them all in a keyboard state map of its own. When checking for a key, it checks this internal map. Due to what could well be timing issues on Macs, Noxico's view of the keyboard state does not match that of the actual keyboard.

And that's why I rewrote the input system to use a buffer instead of a map. Please give this fork of 0.1.15 a try and tell me if it's any better. [i]Some things may not work exactly right[i] because I focused on basic interactions and not breaking UIText.

I don't just program Noxico...
Posted on 03-21-13, 11:34 am in Random list of suggestions:
<i>Prophet of Celestia</i><br>Baka on the streets, senpai in the sheets
 

Posts: 207/344
Since: 06-08-12

Last post: 665 days
Last view: 205 days
Let's go over your list, then.

• Pets: a very good idea.
• Polymorphitis: to be considered. The way Nethack works makes this relatively easy, but perhaps random shifts towards target forms... chimerism?
• Wearable characters: a slime armor was in development, but that technically killed the slime.
• Change size: halfway there, nothing about your height stops you from proceeding at this time.
• Exploration: already there. NPCs can mention locations, which are then added to your travel map. They don't exist until you actually go there.
• Bones maps: already there, in a debug-cycle sort of sense?
• Sharable maps: can't be (easily) done.
• Claimable homes: planned.
• Android version: jokingly planned because my dad.
• Save points: interesting idea.

I don't just program Noxico...
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Main » Kawa » List of posts