🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

JJXB

34
Posts
16
Topics
1
Following
A member registered Jun 29, 2016

Recent community posts

i would be interested in the idea of script-controllable camera movements but partially because i'm curious how the whole sort of flashy "auto-rotating" camera thing that i'd try to script would work out for this.

Figured i'd throw my skills at something else that might be interesting with the scripting work i do. how's about turning a flat snooker game into a fully 3D one? if anyone wants to muck around any further then it's up to them but hey, nice to be able to use it on something more sedate. I did also do a chessmaster 3dn at one point but i'm gonna redo it.

Also: Check the scripts for improvement on how i positioned the Y/Z field.

3dn file

I just got my iPega 9068 working again after some weirdness with the analogs and i was curious would phones and things like that be strong enough to support 3DNes and maybe the VR stuff via cardboard? Unity being on android should work fine so if there was a barrier it'd be more "would there be the hardware to run it" and "would you want to work on it?" (i understand if you wouldn't but i figured it'd be better to ask than not to ask)

Okay, simple one this. but i figured i'd throw in two ways to play: the simple standard viewpoint way and the more challenging from behind view. I'm putting it here instead of in "complete" because i'm sure this can be tweaked.

3dn link

road appears to be empty colour as far as i know considering how it gets treated. but i might be wrong on that front as well.

glad to know my weird experiments on things helped spark some sort of solution, especially since i'm finding less weird stuff to experiment with that i know is doable as is (exerion being an odd thing to try and work with and solstice being an example of screwy tile work getting in the way of things)

damn that's good. i notice the rotation and stuff i did isn't in there but that's fine because most of the stuff i do with scripts is on a testing basis anyway. did my attempt inspire/help you to get it going again?

(Edited 3 times)

this is just one of those ones that were the equivalent of "throw something until it sticks". and this one did work but i didn't want to upload it literally just after i had just uploaded chase H.Q. either way, this works well enough that you can probably just tweak bits and it'll be done.

also: don't try and take some games on (hint: solstice will be night on impossible at all because of it's tile arrangement but that will be another thread entirely).

3dn

Edit: Video!

(Edited 1 time)

3dn


me being the fool that i am, decided to work on trying to modify your 3dn. while nowhere near perfect (jumping being a problem still but more on that later), this is how it came out. 

that jumping problem? my only idea on that is to use the Z position of the shadow itself and then use that to work out where on the Z plane the bike itself should be since logically the shadow should be underneath the bike. plus this modification makes the ram mapping issue moot mostly. Edit: fixed a couple of errant ramps and excluded any air tagged elements from the actual y algorithm (neither change reflected in the video)

either way, give it a go and see if my modification has made it easier for you to handle things.

ah. makes sense then. i'll keep that duly noted

(Edited 1 time)

i've not gone very far into the game myself as far as playing so you'd be best off just starting from the beginning if you want to try it out but i'll add the state to first post anyway. and what's the syntax for clipping? Clipping=8, Clipping.y=8 ? once i have that down i will be able to note it down in my big text file of reference material (including scripts). if you want to see said txt at some point to find out what i found useful to note down for myself, you can ask on here or discord (since you have me added on there) :)

(Edited 1 time)


3dn Link

Savestate

the 3D slant itself works a treat and because the sprites are mostly together there's not much issue with split-tiles. however, i'll probably wait until some sort of texture import/export is done for this one because getting the buildings in full 3D would be a hell of a task with the existing texture editor.

Edit: added Savestate on geod request

figured i'd try an into the screen racer and while there's minor kinks, i've managed to get a decently working example up that can be worked from.

3dn file

so that's where i was going wrong. I'd suggest putting notes into the documentation on small bits like that where relevant though since things like that will help anyone else wanting to try and script for this.

(Edited 1 time)

well then, thanks :) trying to figure the stuff out was something i took longer to figure out than i'd like to admit overall but i got there and cleaned up the code enough that it doesn't look like an absolute mess.

it just always seems very intermittent as to when hex addresses work for me in some instances. and on WriteMem it tends to not accept values to write like 0E or 1E but accepts E on it's own (the error with the previous examples being malformed number error). is that just me doing something wrong or is that another thing entirely like the address has to be in hex but the value to write has to be in decimal?

yeah, scripting reuse. thankfully, the sprites in this weren't an issue with changing Y to Z.

River City Ransom if you recall the other thread on it.

done.

(Edited 1 time)

i suspect that if there's multiple shadow sprites you could use tags and then in the code have tags change y things accordingly? i did consider trying that in RCR but it'd be too inconsistent in that considering how sprites got split up in that compared to maybe this. plus this seems like there's less sprites to tag here if you were to try that approach anyway.

edit: by this i mean multiple shadow sprite tags like maybe "shadowground" and "shadowair", then taking slightly different action from ramps by using the said tags.

(Edited 3 times)

After an extensive rewrite of the field handling, i am proud to say that the functionality of both the road and the cars are now working! i'd have to tidy up some of the 3d shapes but everything is being auto-layered via script so it won't look stupidly out of place. oh and there's a cheat script in place that you can easily disable.

rename as needed.

edit: got to reupload it

Edit 2: as of further testing there's very minor bugs but still very usable. 3dn

Edit 3: screenshot added

(Edited 2 times)

well then. shame that i doubt these will help as much as i'd like since the issue i'm currently running into is instant death (might have to patch ASM for that but i'll be seeing how i can do that via scripts since all of my patching of ram is tending to be via Script:WriteMem rather than patching GG codes into the roms)

Edit: FCEUX worked well for making sure i could get the codes into hex addresses at least so i'll give them a shot since the infinite jump code might be useful after all.

Edit 2: Nope, can't get the codes even going because trying to get them in via WriteMem just breaks things and i'd rather not patch my rom file.

okay, updated 3dn file. the road is in a semi-working state but the actual cars work and you could "play" it in this state:

3dn File

(Edited 1 time)

i think i've run into the same issue in further probing with Road Fighter that you describe with the rippling effect and i don't have a solution for it either. there again i've been doing a lot that i haven't been uploading as well because they are too messy to show and have run into some weirdness that i can't solve due to game tile weirdness (exerion, rad racer, Mystery World Dizzy).
As for the first question, there's a lot of stuff that you might be able to change with scripting in my experience (still not as good as geod's considering things but i'm getting there) but how you change it might depend on what is readable and writable as far as functions (again, i refer to geod's wisdom there)

i figured that while the color indexing might be a problem, it'd be less of a hurdle than trying to add stuff like free select/magic wand into the texture editing interface within unity.

I've been thinking on some things and thus i know there's a 3dn file out there for this already but i wondered if i could use the work i've done on RCR in any other games and it actually work without any problems. as it turns out, yes!. so while very incomplete and buggy, this is my initial work on getting this to work in third person via playfield manipulation if anyone wants to either try it or improve upon it.

3dn file

e.g. tga or some sort of commonly readable uncompressed format so edits to some things can be done easier in external tools then reimported into 3DNes since the editor for patterns as is not terrible but the inability to delete a large swathe of bigger bits of pattern work without going in and using the pen/fill on tiny areas that have a lot of seperated pixels is kind of tedious where it's needed.


plus i figure that i'd be harder to add a select tool into the existing editor than to add the possibility of trying to get the patterns into an external image file, edit them with existing software (paint.net/photoshop) and re-import them.

Savestates

3dn file

Beaten the first boss, got some way to the second but the difficulty curve of the game is making me want to throw something out of the window so i throw in the towel at the moment.

UI-wise, most UI stuff is sorted, and everything up to the point of my last savestate (BK2.sav) "should" be done. and the scripting side of things is relatively simple when compared to zelda or river city ransom so i ran into no headaches with the modifications themselves, only how difficult the game is, even on easiest.

3dn File

massive mess right now because all i've really worked on is the scripts. i have things moving on the Z axis but i have these troubles:

1. Determining jumps without memory addresses (so i can apply it to multiple objects at a time without laborious tagging and duplication of scripts to adjust memory addresses). I could do it by animation shapes but even then, it wouldn't work entirely correctly afaik

2. Adjusting multiple sprite shape offsets without duplicating scripts or massive branching complications even on the player character alone. as is, things move on the X and Z axis in the 3dn file but the individual elements of the sprites do not join, instead they go one after the other (check the file and see what i mean). the main reason for this is because i have a static high and low variables set because i see no way of getting the highest and lowest possible numbers for an individual sprite shape and adjusting accordingly, meaning every sprite shape is at the same level even though the top, middle and bottom of the player character shapes have different y coordinates and different highs and lows for it to be even and join up right.

that works for it but had to do two different variations since the sub stage split up into two. and i did get the entire stage done earlier. THEN LOST it so i'm not going back to it for the second

(Edited 1 time)

what eventually got it reading anything at all was to enter Script:ReadMem(B9). but now i'm running into the issues of:

1. setting z1 not having any effect on object position at all.

2. the fact that when y1 is set to read from B9, it keeps spitting out numbers that are inconsistent with the information in the linked FCEUX lua repo (constantly changes between higher values than it should and zero even when the player is standing. gonna investigate more in FCEUX myself just to see if there's something i'm missing though. because applying the value from B9 to the shape.Offset.Z of the player sprite, it flickers between way out into the field and back to where it was.

Edit: okay, i solved most of that. the trouble is now i can't rely on memory addresses because if i want it to apply to enemies there's too many memory addresses i'd have to look up per the fact that there's multiple enemies. and also items. i'll post my current 3dn in the WIP section but unless you can get certain states without memory address reliance, i think i'm probably gonna only poke at it every so often.

also: video of the issues i am facing with the sub stage because i'm tearing my hair out trying to get this not to mess up: Link

okay, coming back to it every now and then there's been one major issue with the scripting that i cannot get past: i can't seem to get ReadMem to even work. without quotes in the brackets, 00B9 is seen as a malformed number and with quotes inside the brackets, i get an error about trying to index a null value. I've tried appending ReadMem with both Script. and ScriptManager after having once again looking through the scripting manual itself. am i doing something wrong or have i just stumbled upon a bug?

Newer version. Fought through 3 more stages (so, A, B, D and F). the sub stage is a WIP and the other stage hasn't been touched. running into shape/tile issues in the sub stage because background piping and main stage piping use the same tiles and thus it's being awkward with the shape/tile things and even cloning causes weirdness.

4/6 Stages complete

(Edited 1 time)

I went back to my V1 Shatterhand 3dn and re-imported it. spent god knows how long tweaking UI scripts, enemies in the first stage again and trying to get somewhere. i haven't got very far past first stage mind you but most of the first stage should be done (including a chunk of the boss animations and at least two powerup robots).

Shatterhand V2 3dn

.Sav file to get to the post stage 1 select screen.

notes on the script in the file: if you want the UI to ignore an element (if you're modifying it), just tag the element (no matter the layer) as "background" (no quotes).

figured it was worth asking about and the reasoning makes sense. though in the scripting manual it also says that things like Rot, Offset and Pivot are also listed as get only:

PVector3 Scale { get; }
PVector3 Rot { get; }
PVector3 Offset { get; }
PVector3 Pivot { get; } // the pivot of scale and rotation operation

even though you can have a script modify those temporarily. are those only modifiable because those aren't recalculating all the data per frame, just that one attribute?

duly noted. got it put down in a seperate file along with relevant sections of the ram map (i gathered the Y position in NES memory in itself would also be useful so i noted that with the how far player is above ground level address) and your advice. for the moment i'll be looking at other projects scripting wise though.

looking through the scripting manual, it seems that you can't change the geo shape of an object from a script, only read what type it is. am i misreading things or are you planning to add that as a feature?

what would the best way of doing something with the whole "location on the vertical of the screen is reflective of left to right"? I assume that it'd first be a check for if the character is going up or down on the Y axis then use that to change the Z offset on the fly sort of deal thus far.

but if i have the ground at a 90 degree x rotation, that doesn't fix the fact the character goes down on the screen. so unless i do on the fly Y offset correction too, it'll look weird. with the ground at 45 degrees my initial idea would work but not look as good. thoughts on it?

PSM unity on vita doesn't work past a certain firmware so you'd be on your own putting unity onto the vita itself (you need 3.60 for the main exploit on vita anyway - henkaku/taihenkaku and no-one's found a way of getting PSM unity stuff working again on it yet)

i found tridef 3d ignition works with it when in dx9 mode (dx11 mode it crashes). doesn't suit FPV function though.