Jump to content

Frionil Fang

Resident
  • Posts

    371
  • Joined

Reputation

553 Excellent

Retained

  • Member Title
    script cat

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Like Wulfie said, most of these are no help without type punning and/or unions. There's also the fact that user-defined functions are *slow*. From a quick test, 100000 square roots takes less than a second; 100000 user-defined square root function calls to a single-iteration Newton approximation (which is obviously terrible and useless) already takes more than twice as long. With a reasonable number of iterations, we're talking ~10x as long. Consider what you are using these rotations for, too: nlerp is already meant to be fast and loose, functions that don't require normalization (like plain old llSetRot/PRIM_ROT) will work even if the results might not be accurate, that probably wasn't the goal in the first place. Functions that do require normalization (llSetKeyframedMotion comes to mind) won't be satisfied with a sloppy approximation, they need the magnitude of the rotation to be close enough to 1. TL;DR stick with multiplying by 1/llSqrt(mag) for accuracy, leave it out entirely for speed if it works.
  2. Yes, I know, that's when I made the expansion: fitting 60*1 kB memory banks into linkset data (the other 4 stay in script memory), when you have no binary encoding, was more or less an impossible task. It uses base64 to achieve a 3 bytes into 4 base64 characters -ratio without a too horrible hit to performance on swapping. Hex dumps would be more performant, but that gets a measly 1 byte per 2 characters, and is used only for the system bus/DMA, and wouldn't leave enough linkset data space for all the other stuff.
  3. Yeah, I could retroactively go and just add line breaks anywhere especially now that the storage device uses -Sync reading, the file is a contiguous block of data and linebreaks don't matter for how the computer itself sees them, but I'd rather them just fix the regression sooner than later.
  4. That may have been me, though I know I'm not the only person to write a 6502 emulator in LSL. It's not cycle accurate and forgoes emulating many of the hardware quirks (illegal opcodes, RMW behavior) and BCD arithmetic mode, the NES did fine without the latter. It doesn't emulate a real computer either, instead implements its own "hardware" so it won't run any code that isn't written for it specifically; the CPU runs at roughly estimated 400 Hz instead of 1-2 MHz so it's not exactly going to be competitive with an Apple II, C64 or NES, so I figured to just give it appropriate peripherals rather than try to target a real architecture. It used to have only 8 kB of memory, all I could fit into the main CPU+memory+system bus script, but it now uses linkset data to swap 1 kB memory banks and can see the entire 64 kB address space, keeping 4 banks in script memory. Not that there's any reasonable way to use up such massive quantities, 64 kB? The biggest program I've made for it is just over 3 kB, and that's mostly just graphics. To stay on the topic of notecard reading though... can't see any corruption in the above picture thanks to fortunate positioning, but it's there. The data storage device reads arbitrary files as hex dumps and crams them into system memory. The files were laid out as 1024 character lines (512 memory bytes per line, in other words) to minimize the amount of lines to read, everything already runs at a very retro pace and no need to make it any slower. Now that even the old notecard reading function broke and returns only 1023 hex digits, the last byte on each line is misread, and with the way the system's video memory is laid out in 4+4+8 bit units at 32x24 character resolution (background color, foreground color, character) this means one character every 8 lines is corrupted. Also not noticeable on most of the corrupted lines, but bottom right corner is clearly wrong: it's supposed to be character 0xBD, the storage device detects the missing nibble and kludges it into 0xB0 (it would otherwise end up as 0x0B). Thankfully it was just a picture and not code, you wouldn't want your LDA <16-bit address>,X opcode to turn into BCS <signed 8-bit offset>. Just for fun, below is the program+data in the notecard:
  5. My SL computer loads programs that are written as hex dumps into notecards. Because notecard loading was so painfully slow, minimizing the line count was important and maxing out line length was a good idea. Sure, reading with the sync notecard reader is so much faster that using, say, 512 character lines would no longer be a limiting factor in loading speed, but that doesn't change the fact that no script that was relying on 1024 byte lines works anymore until they fix their regression. Anyway, wrote the bug report: https://feedback.secondlife.com/scripting-bugs/p/server-version-2024-02-217995320426-broke-notecard-reading-limit
  6. They broke it though, and broke llGetNotecardLine at the process. llGetNotecardLine and llGetNotecardLineSync now return only up to 1023 bytes (used to be 1024 for async) and I was relying on that behavior. Time to write a jira uncanny canny feedback.
  7. Only PBR-material faces are not rendered.
  8. That doesn't "turn PBR off", it just disables rendering of anything using PBR materials. Anything else is unaffected, including the lighting.
  9. One last idea... your mesh wouldn't be using PBR materials, would it? Old SetColor/SetAlpha/SetTexture don't work on something that has PBR materials applied; you're changing the underlying old parameters, but the PBR material ignores those and uses its own settings. You'd have to use the glTF overrides instead.
  10. Your state_entry sets alpha on the root prim to 0 on all faces, but your touch event sets textures on face 5 and doesn't set it visible anywhere? The page2 state also sets alpha to 1 only on face 3, which isn't something that's being changed here. As a side note, it's not safe to change state from a touch_start event, it's bugged and may end up losing the next touch event. Should change state from a touch_end event instead.
  11. Completely useless tidbit but since I just read about it for unrelated reasons, on x86 (integer) modulus and divide are the same operation, you get the other one "for free" at the same time. DIV (unsigned) and IDIV (signed) produce both the quotient in AL/AX/EAX/RAX and the remainder in AH/DX/EDX/RDX.
  12. There's a string indexing error in the function, making it return FALSE unless the strings match exactly. That wouldn't cause a math error but dunno. You're giving the substring length as the ending index to llGetSubString, but it returns the characters *inclusively* between the indices so it should be decremented. For example your beginsWith("abcd", "abc") would get string length 3 for the prefix, and would then compare llGetSubString("abcd", 0, 3) => "abcd" to "abc", failing every time unless the strings match exactly and the overflowing ending index compensates. For instance, check the string length being 0 before comparing (separate if clause to avoid the string function being evaluated if the string length is 0, I guess, LSL logical AND/OR aren't shortcutting so every part of the statement gets executed), and then use length-1 instead. integer beginsWith(string str, string substr){ integer ss_length = llStringLength(substr); if(!ss_length) return FALSE; if(llGetSubString(str, 0, ss_length-1) == substr) return TRUE; return FALSE; }
  13. If you're talking about streamed parcel music fading in and out, that's been happening for some 7 years now across 3 different computers and several ISPs. I do some lowkey DJing and it happens once or twice per set for me. The viewer uses a premade library for handling audio streams and it's just configured weird or buggy, occasionally running out of data and fades out for a moment. Never found any good manual fix or explanation, and it's clearly not high priority on LL's list of bugs, dunno if it even happens for everyone. Edit: parcel media/media on prim like youtube do not use the parcel audio stream, so they wouldn't suffer from that bug.
  14. Games often include a brightness/gamma setting, but here's the thing... they're games, made with consistent art direction, the content in scenes designed to work together, so there's not much need to fiddle with things to make mix'n'match work. There's the reference environment you could design on (https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi) but I don't see it being very foolproof in practice, not that baking in lighting and eschewing any materials or using old Phony-Bling materials is any more so.
  15. The supported character set could be changed, but you'd have to change the typeface textures as well, etc. As seen above, the set defined in the code is as follows (though it appears to be missing a couple of the line-drawing characters for some reason, maybe the version I checked is old or something):
×
×
  • Create New...