1
0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-11-10 20:09:58 +00:00
Commit Graph

10 Commits

Author SHA1 Message Date
Jonathan Coates
0c0556a5bc
Always use raw bytes in file handles
Historically CC has supported two modes when working with file handles
(and HTTP requests):

 - Text mode, which reads/write using UTF-8.
 - Binary mode, which reads/writes the raw bytes.

However, this can be confusing at times. CC/Lua doesn't actually support
unicode, so any characters beyond the 0.255 range were replaced with
'?'. This meant that most of the time you were better off just using
binary mode.

This commit unifies text and binary mode - we now /always/ read the raw
bytes of the file, rather than converting to/from UTF-8. Binary mode now
only specifies whether handle.read() returns a number (and .write(123)
writes a byte rather than coercing to a string).

 - Refactor the entire handle hierarchy. We now have an AbstractMount
   base class, which has the concrete implementation of all methods. The
   public-facing classes then re-export these methods by annotating
   them with @LuaFunction.

   These implementations are based on the
   Binary{Readable,Writable}Handle classes. The Encoded{..}Handle
   versions are now entirely removed.

 - As we no longer need to use BufferedReader/BufferedWriter, we can
   remove quite a lot of logic in Filesystem to handle wrapping
   closeable objects.

 - Add a new WritableMount.openFile method, which generalises
   openForWrite/openForAppend to accept OpenOptions. This allows us to
   support update mode (r+, w+) in fs.open.

 - fs.open now uses the new handle types, and supports update (r+, w+)
   mode.

 - http.request now uses the new readable handle type. We no longer
   encode the request body to UTF-8, nor decode the response from UTF-8.

 - Websockets now return text frame's contents directly, rather than
   converting it from UTF-8. Sending text frames now attempts to treat
   the passed string as UTF-8, rather than treating it as latin1.
2023-11-08 19:40:14 +00:00
Jonathan Coates
52b78f92cd
Use standard Markdown link syntax for references
References are now written using normal links: You now use [`print`] or
[print a string][`print`]) instead of @{print} or @{print|print a
string}.
2023-08-24 11:23:33 +01:00
Jonathan Coates
2055052a57
Switch to GitHub-style admonitions/alerts
As these are just a custom syntax on top of blockquotes, these work much
better with text editors.
2023-08-23 18:10:01 +01:00
Jonathan Coates
895bc7721a
License CC:T according to the REUSE specification (#1351)
This adds SPDX license headers to all source code files, following the
REUSE[1] specification. This does not include any asset files (such as
generated JSON files, or textures). While REUSE does support doing so
with ".license" files, for now we define these licences using the
.reuse/dep5 file.

[1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
Jonathan Coates
a9b74dc979
Make IRC links https 2022-10-09 11:22:24 +01:00
Jonathan Coates
e7533f2353
Improve community links a little 2022-09-29 22:01:51 +01:00
Jonathan Coates
87a1c1a525
Some minor documentation fixes
- Add a TOC to the Local IPs page.
 - Increase the echo delay in our speaker audio page to 1.5s. This
   sounds much better and is less clashy than 1s. Also add a
   sleep(0) (eww, I know) to fix timeouts on some browsers/computers.
 - Move Lua feature compat to a new "reference" section. Still haven't
   figured out how to structure these docs - open to any ideas really.
 - Mention FFmpeg as an option for converting to DFPWM (closes #1075).
 - Allow data-mount to override built-in files. See my comment in #1069.
2022-05-05 13:27:33 +01:00
Paspartout
fc4569e0cc
speaker_audio.md: Fix missing add/sum typo 2022-01-13 17:36:26 +01:00
Jonathan Coates
afd82fbf1f
Add speaker support to the documentation website
Happy to pick a different piece of audio, but this seemed like a fun one
to me.
2021-12-21 22:20:57 +00:00
Jonathan Coates
b048b6666d
Add arbitrary audio support to speakers (#982)
Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a
resolution of 8 bits. Programs can build up buffers of audio locally,
play it using `speaker.playAudio`, where it is encoded to DFPWM, sent
across the network, decoded, and played on the client.

`speaker.playAudio` may return false when a chunk of audio has been
submitted but not yet sent to the client. In this case, the program
should wait for a speaker_audio_empty event and try again, repeating
until it works.

While the API is a little odd, this gives us fantastic flexibility (we
can play arbitrary streams of audio) while still being resilient in the
presence of server lag (either TPS or on the computer thread).

Some other notes:
 - There is a significant buffer on both the client and server, which
   means that sound take several seconds to finish after playing has
   started. One can force it to be stopped playing with the new
  `speaker.stop` call.

 - This also adds a `cc.audio.dfpwm` module, which allows encoding and
   decoding DFPWM1a audio files.

 - I spent so long writing the documentation for this. Who knows if it'll
   be helpful!
2021-12-13 22:56:59 +00:00