Project Announcement: EmoSTEP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Project Announcement: EmoSTEP

Jeremy L.
Currently, there's a resurgence of appreciation for the aesthetic of old computer hardware.  The popularity of such 'fantasy consoles' like Pico8, TIC 80 and Pixel Vision 8 are following the long-lasting wave of retro-computing which has only gained momentum since the introduction of the first popular 'retro emulator', NESticle in 1995, an emulator that mimicked Nintendo's original flagship games console from 1984.  I don't foresee this aesthetic going away any time soon and it is quite inviting for kids and adults who want to try their hand at making something on the computer but don't want to be bogged down with the current generation's level of complexity.  Even the basic low-resolution graphics inherent to these old systems invite the most novice of artists because there's no expectation that anything will look 'polished' in the way that modern 3D games and applications look.  By their very nature is a concrete limit as well as a 'challenge' to make just a few pixels resemble an idea.  Combine this with these graphics and sounds requiring imagination to be 'complete' by anyone else who looks at it, it becomes quite an interesting medium to explore even for people who've gone through thousands of hours of graphics and audio instruction and training; the possibility of someone without this experience producing something that stands up to the work of a professional is much higher than in high-resolution, high-definition settings.  

My project involves a complete makeover of Etoys so that it retains functionality of Etoys/Smalltalk at it's core, a system that is itself already inviting, with the inviting nature of low-definition visuals and audio.  Using the already-made classes such as OLPCVirtualDisplay and FMSound, the idea is to follow the concept of projects like Pico8 as a 'fantasy console' and make a 'fantasy computer' running a 'fantasy OS', which at this point is dubbed EmoSTEP.  It also is highly dependent on having some good demonstrations how to think about this version of Etoys and minor additions/changes to some of the tools so that everything marries together in a cohesive feel.  

I myself am not a programmer by trade, I'm actually in the middle of a career change from electronics technician/grunt to graphic design (I am in my last year of school), so a lot of the things I've been doing programatically have been very slow as I'm learning how to implement these ideas as I go.  And you know what that means:

The purpose of this project is not to supplant or replace Etoys at all or even be considered part of the 'main Etoys goals', but to provide an alternative entrypoint for those interested who cannot see beyond the initial look of Etoys what it's capable of.  In fact, one of the main goals I have is to keep projects made in this hack completely Etoys compatible so that a project made in EmoStep loads like any other Etoys project into the official Etoys release (and of course, later, Squeak).

Aspects/applets that are intended to be included are as follows:

Low Color Depth (I need to hack the 8bit palette maker to not simply produce 248 shades of gray and 7 'regular colors' but be a true approximation of a full 16bit/32bit depth color range but executed with fewer colors to select from...)

Pixel-Art Oriented PaintBox (currently, the GSoC Paintbox edit and built in Paintbox are only capable of really bad high res/low color art work.  What is needed are special brushes for 'lighten/darken', pattern/stipple brushes etc.  See GRAFX2 application for an idea of tools that need to be implemented)

FM Sound Composer (restructuring the old Squeak code that allows editing and creating of FM instruments/sounds and musical compositions and accessing the creations via Etoys viewer flaps)

Demosdemosdemosdemos (lots of cool little 'applet' projects that demonstrate commonly sought-after effects and basic game-engine operations)

Faux "This Is An Emulated Machine" Aesthetic (rather than making it seem as if it's just a programming language, take the approach interface-wise that mimics *some* aspects of 90's computers, such as startup/shutdown screens, reconfiguring windows themes with a theme editor, icon makers, etc.)  

I hope other people are interested in this project.  I feel that much of Smalltalk/Etoys lack of traction in these days where terms like 'retro' and 'livecoding' are all the rage fall directly on aesthetic and approach to the system and that's really what, ultimately, is the aim of the project; introduce more people to the world and especially the history of smalltalk.  

The name EmoSTEP itself is a bit of satire on the negative effects of Steve Jobs short sightedness to sellsellsell has obscure the real purpose of the work he and his team cannibalized for the Lisa, Macintosh and NextStep computer lines.  Namely, it made it easier for 'scribes' to pump out one-size-fits-all style programs which mostly don't fit anyone rather than the real goal of the Smalltalk team which was to make it so that people could build their own software when they need/want it by borrowing from the works of such scribes without restrictions.  EmoSTEP is short for "Etoys Morphic OS SmallTalk Experimental Programming" or something of that nature.  I came close to just calling it AmigoSTEP, but truth be told, the name isn't solid just yet, so if anything, maybe someone's got some clever puns to throw out at me.  

Anyway, here's a pile of screenshots for some work towards this project, both in Etoys and the edited image with the low-fi graphics already operational at a pixel-density level (the color depth issue noted above is still on the to-do list).

I'd love comments, critiques, insights, flames, etc. and welcome any assistance and guidance from people that understand the underlying smalltalk much better than I.  I kind of regard it as a minor miracle I've been able to do as much as I have thus far, a true testament to the language and it's immediacy of the environment, something I hope to turn up to 11 with this project.

Thanks for reading this long message!

various random images from work on this project in no particular order of importance--> https://imgur.com/a/0PT4B







_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Project Announcement: EmoSTEP

Jecel Assumpcao Jr
Jeremy,

>[emoStep and retro visuals]

Nice project! I think packaging Etoys for such use is a good idea.

In the case of Smalltalk, the true retro visual would be high resolution
black and white, which is not at all nice for games (even though we put
up with it on early Macs).

I started designing computers for children in 1983 and Smalltalk
computers the following year, so what was the best I could do back then
was what you would consider retro. If I could go back I would have
focused on 320x256 or 256x192 with 64 colors. Having 2 bits each for R,
G and B is the very first step towards "true color" (do an image search
for "ega art"). For modern hardware (even the first Raspberry Pi) there
is no point in having such limitations.

-- Jecel
_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Project Announcement: EmoSTEP

Jeremy L.
Indexed palette is definitely what I want to include.  As far as B*W/1bit, I'm actually a big nerd/fan for black and white displays.  They silently put a focus on making things rather than deciding how they should look...because let's face it, if you're not busy deciding what color to make your car, then you should be already making your car!  Since I'm looking at the Amiga 500 and Atari ST as main inspirations on how to make the project 'appear', I've been kicking around the idea similar to what you mentioned, but with both included: namely a high resolution b&w mode and low resolution indexed palette/color mode.  That way, if nothing else, the high resolution B&W might be considered a way to get more screen realestate for etoys scripting that gets complicated or for people who are just discovering the smalltalk/squeak underneath while the lower, color resolution would be ideal for 'presenting projects'.  

It's still undecided at this point, but is also going to heavily depend on how fast/much I can learn smalltalk as I go.  I'm not a programmer in the way many of you are, I'm more of an artist hacker, and thus my abilities to bring such things to life is limited by this!  

Thanks for checking it out!

On Wed, Jan 24, 2018 at 6:33 AM, Jecel Assumpcao Jr. <[hidden email]> wrote:
Jeremy,

>[emoStep and retro visuals]

Nice project! I think packaging Etoys for such use is a good idea.

In the case of Smalltalk, the true retro visual would be high resolution
black and white, which is not at all nice for games (even though we put
up with it on early Macs).

I started designing computers for children in 1983 and Smalltalk
computers the following year, so what was the best I could do back then
was what you would consider retro. If I could go back I would have
focused on 320x256 or 256x192 with 64 colors. Having 2 bits each for R,
G and B is the very first step towards "true color" (do an image search
for "ega art"). For modern hardware (even the first Raspberry Pi) there
is no point in having such limitations.

-- Jecel


_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Project Announcement: EmoSTEP

Jecel Assumpcao Jr
Jeremy,

> Indexed palette is definitely what I want to include. 

I've always hated that even though memory limitations forced me to
include it in my hardware designs. I was so glad when we left that
behind at the turn of the century. On the other hand, it was a neat way
to add amazing water and fire effects to an otherwise static background:

http://www.effectgames.com/demos/canvascycle/

I wonder how well this still works in Squeak? When people make changes,
they tend not to test things that they don't use themselves leading to
"bit rot". Since I ran Squeak 3.x on a machine with only 256 colors I
know it worked back then. But I never tried the indexed modes when the
hardware was true color.

> As far as B*W/1bit, I'm actually a big nerd/fan for black and white
> displays.  They silently put a focus on making things rather than
> deciding how they should look...because let's face it, if you're not
> busy deciding what color to make your car, then you should be already
> making your car!

You worry about textures instead :-)

> Since I'm looking at the Amiga 500 and Atari ST as main inspirations
> on how to make the project 'appear', I've been kicking around the
> idea similar to what you mentioned, but with both included: namely
> a high resolution b&w mode and low resolution indexed palette/color
> mode.  That way, if nothing else, the high resolution B&W might be
> considered a way to get more screen realestate for etoys scripting
> that gets complicated or for people who are just discovering the
> smalltalk/squeak underneath while the lower, color resolution would
> be ideal for 'presenting projects'.  

Well, the ST actually had separate outputs and monitors for the two
options. And the OLPC machine had a black and white mode for outdoor use
(you needed the backlight for color). Even the Xerox Alto, which was
famous for the high resolution black and white monitor, had an optional
(and rare) color board.

Etoys doesn't have a separate development and presentation mode but
Scratch does so it seems people are ok with that.

> It's still undecided at this point, but is also going to heavily depend
> on how fast/much I can learn smalltalk as I go.  I'm not a programmer
> in the way many of you are, I'm more of an artist hacker, and thus
> my abilities to bring such things to life is limited by this!  

There are many levels of programming and what you want to do is a bit
advanced. It is always hard to do this kind of project by yourself
instead of as part of a group of people with different talents.

-- Jecel
_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Project Announcement: EmoSTEP

Jeremy L.


On Thu, Jan 25, 2018 at 10:26 AM, Jecel Assumpcao Jr. <[hidden email]> wrote:
Jeremy,

> Indexed palette is definitely what I want to include. 

I've always hated that even though memory limitations forced me to
include it in my hardware designs. I was so glad when we left that
behind at the turn of the century. On the other hand, it was a neat way
to add amazing water and fire effects to an otherwise static background:

http://www.effectgames.com/demos/canvascycle/

It's funny you show that screenshot as the artist of that piece gave a great "You kids today don't understand!" talk at GDC about retrographics and how most people do it incorrectly, to which I'd have to agree, considering that photoshop is not the tool to make this kind of thing yet if you search 'pixel art tutorial' anywhere, 95% of the time will be a bad lesson where someone insists on using a tool that cannot handle palette manipulations the way software like GRAFX2 or DeluxePaint can.  They even insist on hand drawing the stipple patterns!  It's insanity!  He also mentioned in that talk that he really hated being limited in color, so I know it wasn't just you!  But he does go on to say that the way palettes are handled when limited is far more capable of special effects on the cheap and is more fun for him to explore from an artist perspective.  I agree with that as well as I've spent hours exploring effects like that in GRAFX2...there's a lot of unexplored territory and I do hope to bring that frontier in some form into this hack of Etoys.

I wonder how well this still works in Squeak? When people make changes,
they tend not to test things that they don't use themselves leading to
"bit rot". Since I ran Squeak 3.x on a machine with only 256 colors I
know it worked back then. But I never tried the indexed modes when the
hardware was true color.

It's still working, it seems!  I've run a couple of the tests in the EToys image of the blitter, one of which was a palette rotation demo and it worked nicely.  I was also able to 'recreate' it using Etoys script and 100 overlapping objects and while not quite as fast, it was a lot faster than I expected, considering how many specific objects were getting color change commands.  Even on underpowered/obsolete (by today's standards) hardware.  It's a great, cheap way to make things look like they're moving without using up a lot of draw time.  There's a fellow who is using Cuis Smalltalk that is looking into optimizations of drawing based on order and viewability/obscurity as an optimization so that things hidden aren't drawn.  I doubt I'll be able to 'port' any of that into Etoys, but his work is on my radar.  He demo'd a very preliminary implementation here:




> As far as B*W/1bit, I'm actually a big nerd/fan for black and white
> displays.  They silently put a focus on making things rather than
> deciding how they should look...because let's face it, if you're not
> busy deciding what color to make your car, then you should be already
> making your car!

You worry about textures instead :-)

Yes yes!  Been there...haha...I still, from time to time, play with Cricket Paint on miniVMAC...when I was deciding whether to do this project in color or not, one of the ideas I had was 'Megatosh', the 'what if Steve Jobs had ripped off every thing he saw on that famous trip everyone refers to instead of just the window presenters?  Then I realized it would just be Smalltalk80, so that was a dead-end.  
 

> Since I'm looking at the Amiga 500 and Atari ST as main inspirations
> on how to make the project 'appear', I've been kicking around the
> idea similar to what you mentioned, but with both included: namely
> a high resolution b&w mode and low resolution indexed palette/color
> mode.  That way, if nothing else, the high resolution B&W might be
> considered a way to get more screen realestate for etoys scripting
> that gets complicated or for people who are just discovering the
> smalltalk/squeak underneath while the lower, color resolution would
> be ideal for 'presenting projects'.  

Well, the ST actually had separate outputs and monitors for the two
options. And the OLPC machine had a black and white mode for outdoor use
(you needed the backlight for color). Even the Xerox Alto, which was
famous for the high resolution black and white monitor, had an optional
(and rare) color board.  

I'm not especially interested in doing 1:1 recreation of any specific machine, but was thinking of ways to reconcile my nerdy want of a high res B&W mode.  

Etoys doesn't have a separate development and presentation mode but
Scratch does so it seems people are ok with that.


I also don't have any intention of fundamentally changing the way Etoys works or feels.  Most of the 'changes' if you can call them that are primarily in the aesthetics department.  When I mention presentation mode, I was never thinking of making a change, but rather recontextualize what is already in Etoys.  In this case, presentation mode would refer to switching a book/card stack to display full screen.  When not in full screen, it may have reverted back to B&W and the initial project when starting up for the first time would be inside of a book.
 
 
> It's still undecided at this point, but is also going to heavily depend
> on how fast/much I can learn smalltalk as I go.  I'm not a programmer
> in the way many of you are, I'm more of an artist hacker, and thus
> my abilities to bring such things to life is limited by this!  

There are many levels of programming and what you want to do is a bit
advanced. It is always hard to do this kind of project by yourself
instead of as part of a group of people with different talents.

-- Jecel

I'm not new to programming, or young (well, maybe I am in relative terms to some of the people who have worked on Smalltalk over the years), I'm just saying I wouldn't apply for a programmer position outright...let's just say, I'd have a good chance on a team to be lead tester or maybe even a UI programmer, but definitely not the kind of person you would depend on for timely delivery of a brand new structure.  :)  Thankfully, that's mostly all I am doing with this project since some really clever people before me did most of the hard work already.  Open Source FTW.

Thanks for the comments, they were insightful and sparked quite a lot of thought on my end...I think I typed 10x more that didn't make it into the final reply here!  :)  




_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland