In short, it's quite similar to Pico, but enhanced (for example, you can set custom palettes or even "chase the beam", similarly to what you could do on machines like Atari ST or Amiga, which, if done properly can mean breaking out of 16 colors limit. Also sound capabilities seems to be enhanced to what Pico offers, since you can edit waveforms. It has also panoramic screen and slightly higher resolution, both vertically and horizontally (240x136).
It too uses Lua (and Moonscript if you prefer it) and api is quite similar, though not an exact match.
I hope zep doesn't mind me posting there.
Thanks to dddaaannn for letting me know about this stuff.
And as additional discussion seed, have any 3D wizards such as electric gryphon considered porting their stuff to Tic-80? It should be easier to since it has a native trifill function. Also with enhanced graphic capabilities it could look even better.
For now it's just nothing more than a glorified music disk, but maybe I can make it playable? We'll see.
Tried to add drums and bassline (patterns 7 and 8-9, respectively), but I've found it clashing with the melody volume-wise.
I don't want it to clutter my desktop. Saving to the folder where carts reside in would be fine. And if zep is worried static screenshots could mistakenly show up in splore or whatever, due to Pico-8's palette they could be saved as static, single-frame GIFs.
If there's way to customize the location, then sorry but I don't know it.
It'd be a native, free app that would be basically a pico-8 that boots directly to the splore and has devtools disabled. IMO it'd be better if done natively, because HTML5 performance isn't that great to begin with and many android phones are very underpowered and have troubles with running html5 content other than simple videos. As for interface, it'd be quite like regular Android emulators such as e.g. Nesoid.
Basic, easy to use sound/music support is nice, but I'd love access to sound "hardware". Think of it like playing music/sound on your C64 using a mod player vs. writing a program to drive SID directly. This would give us many awesome possibilities that are either impossible or very hard to achieve with the sound system that is in Pico-8. I mean, we can access rendering hardware directly, so why not do the same for sounds?
All it would take is to add following command (name may be different, but gist about the same)
(asnd from advanced sound). It'll play waveform with specific frequency and volume (if either set to 0, it'd just stop playing it) on channel until another "regular" sound is played on that channel, either via music player or via sound command) or another asnd command is issued with that channel name. If channel is omitted, it'll play on first unused channel (with nothing playing on it).
As for waveforms, they're pretty much the same you can set in the sound editor.
The jam would run from May 27th to May 28th (standard weekend jam fare)
The only rules are:
-Include PicoDragonJam in title and tags of your entry thread. If you don't want to spam the forum, a reply to this thread is fine as well.
-The game has to have dragons of any kind in it in an important role (i.e. game where there is a NPC that happens to be a dragon doesn't count unless said NPC wouldn't work just as well if it was of any other species), player character preferred.
The winners will be decided in a vote that will be held on Monday through Wednesday in a public poll.
Haven't used P-8 since 0.1.8 and would like to know what are current limits regarding code size, what counts as a token, etc. If you know of similar fantasy consoles that can be worked with now and not in the planning phase I'd be interested too (though not Pico-8 clones such as PicoLove or Voxatron which I can't afford).
Also, I think the FAQ is outdated:
|When will PICO-8 be finished? What will it look like?|
PICO-8 1.0 will be out sometime in 2016. It will look similar to the alpha versions with the addition of online score submissions and binary exporters.
- It's 2017 now and there's no 1.0 yet.
So here it goes.
The project, due to its scope, is currently at concept stage (no actual code has been written yet).
The idea is to create a "universal" emulator for (fantasy or not) microcomputers. EVC would be fully customizable by loading specific modules for things like CPU, GPU and so on that are basically DLLs written to specific specs. Example cores would be included and entirety would be open source.
There are two types of modules that you would be able to write for the EVC: Core and Generic. Core modules are fixed by their role (GPU module, CPU module and so on). This is planned list for the core modules:
- CPU module
- GPU module
- Drive I/O module
- Peripheral I/O module
- Sound module
- System ROM (firmware)
Last one is kinda special as this would be just a regular EVC ROM compatible with the hardware selected for i/o, gpu and cpu and is executed like any program. System ROM will always be loaded at address 0.
The Generic modules are additional extensions that can be loaded for doing specialized things, such as network communication, ram extenders (if maximum is too low) and so on. Up to 3 Generic Modules can be connected at the same time.
Both Core and Generic modules will have read/write access to the EVC's basic RAM which can be set to anywhere betweem 16kb and 2mb.
EVC ROM specification.
Each EVC rom begins with the EVC header which consists of the following:
32bit integer denoting CPU identifier the rom is made for
32bit integer denoting GPU identifier the rom is made for
32bit integer denoting Sound module identifier the rom is made for
32bit integer denoting Disk I/O module identifier the rom is made for
32bit integer denoting Peripheral I/O module identifier the rom is made for
32bit integer denoting Generic Module #1 identifier required (-1 if less than 1 needed)
32bit integer denoting Generic Module #2 identifier required (-1 if less than 2 needed)
32bit integer denoting Generic Module #3 identifier required (-1 if less than 3 needed)
The rest of the ROM is completely arbitrary and rom size isn't limited in any way. It is up to I/O module to interpret it and load properly. In theory, it should be possible to create set of core and extension modules to emulate say, NES, but then every ROM would need to be converted to contain EVC header before standard INES one.
EVC will be written in Free Pascal using Lazarus IDE
That's all I got for now, please poke holes in this design as it's important to get it as good as it can be before any actual work would start.
Thinking about it, but unsure whether I should post it there or not.
Dunno what causes this weird effect to happen.
Wait about half a minute or so and look at the plane and watch the wall background closely and how things move.
Note that I didn't employ any parallaxing and the only sprites are the plane and the shadows. Yet, at times, especially when it speeds up, things in the background (floor/wall and table/images) seems to be moving at different speeds and sometimes even in different directions. Weird optical illusion/bug in p8. Or I may just be tired and seeing things.
Could it be created so we could produce standalone .exe versions of our games? Basically it would be just regular standalone Pico8, but without devtools (splore, etc. would stay tho). The thing is that webplayer has its limitations compared to standalone and in some cases the webplayer version of cart is unplayable while standalone is working fine.
Any chances of manual, at least on site getting index and links, using a href and a anchor html tags? I mean, it would make it easier than having to scroll down in order to get to the section you're interested with.
I know next to nothing about writing raycasters and demo that comes with Pico is too obfuscated for me. Could someone create a raycaster that can take vector data (sorta like DOOM does) and can render both ceilings and floors? Obviously making it flatshaded since with pico's palette textures wouldn't look good, not to mention texturemapping would be a performance killer for Pico.
Think of the possibilities! And it could be as simple as adding the following function:
freq frequency [channel]
sets channel's frequency to frequency hz. If no channel is provided, 0 is assumed. 0 or negative frequencies mutes it (no sound). Frequency is also reset when sound or music plays on a given channel.
I'm getting back into Pico programming and wanted to do some demoscene effects to warm me up like simple sinewave text. Have trouble with math behind it though.
I want to do first as simple bopping up/down sprite that uses sine behind it. I want to be able to control its amplitude (defined as y offset in pixels from the baseline) and frequency (speed). For now I have formula that goes somewhere like:
where upoffset is mentioned amplitude control defined as max possible deviation from baseline, whether positive or negative, t is time elapsed since start (needed so it will actually bop instead of staying in place) and speed is, well, speed.
Unfortunately speed is somewhat coupled with amp control so when I try to increase speed at which things go, it gets too high/low and vice versa - changing amplitude changes speed at which things go.
Any help? This is best I could come up with and at the rate I'm pulling my hair right now, I estimate to go blind in 36 minutes, 43 seconds and 234 milliseconds.
No need for sample code, the formula will do.
IMO instead of single license checkbox, you should be able to select by mutliple checkboxes the kind of CC license you want for your game.
So, by default it'd be CC0, but then you could check each part of CC license, so you can have any combination of by nc sa nd.
View Older Posts